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Abstract 

Although  concurrency  is  well  known  among  acquisition 
personnel  because  of  the  controversy  surrounding  its  prin- 

i 

I 

;  ciple  application — overlap  of  development  and  production — 

little  documentation  exists  concerning  the  strategy's  his¬ 
tory  or  current  implementation  on  Air  Force  acquisition 

i 

|  programs. 

I 

The  researcher  conducted  a  literature  review^  which 

, 

I  researched  the  history  of  concurrent  and  "crash"  programs 

from  World  War  II  to  the  issuance  of  the  Packard  Commission 

I  l' r  ■  i 

I  Report  in  June  of  this  year.  This  r-e^iew-  focused  on  the 

management  principles  which  were  applied  on  concurrent 
acquisition  programs. 

The  researcher  also  interviewed  twenty  managers 
assigned  to  Air  Force  Systems  Command's  Aeronautical  Systems 
Division  (A SD) ,  who  were  involved  in  concurrent  programs. 

The  interviews  focused  on  the  effects  of  concurrent  weapon 
system  acquisition,  and  the  managers'  personal  opinions 
concerning  the  strategy. 

The  results  of  the  literature  review  indicate  that  the 
meaning  of  concurrency  has  degraded  from  a  specialized 
management  approach  applicaole  to  only  tne  highest  priority 
weapon  system  acquisitions,  to  a  generic  phrase  indicating 


only  overlap  of  development  and  production  phases.  The 
specific  management  principles  applied  on  the  Air  Force 
Ballistic  Missile  Program  and  other  "crash"  programs  are 
outlined  in  the  report. 

The  interview  results  indicate  that  most  of  the  ASD 
managers  interviewed  express  qualified  support  for  the  use 
of  concurrency — provided  its  application  is  necessary  to 
counter  threats  to  the  national  security.  These  ASD 
managers'  opinions  concerning  why  concurrency  is  employed, 
its  advantages  and  disadvantages,  and  their  perception  of 
the  contractors'  and  using  commands'  opinions  about 
concurrency  are  documented  in  the  study.  The  role  of 
Interim  Contractor  Support  (ICS)  on  a  concurrent  program, 
factors  which  reduce  the  risk  of  concurrent  acquisition,  and 
these  managers'  overall  appraisals  of  concurrency  are  also 


HISTORY  OF  CONCURRENCY: 


THE  CONTROVERSY  OF  MILITARY  ACQUISITION 
PROGRAM  SCHEDULE  COMPRESSION 


I.  Rasearch  Problem 

Introduction 

"There  is  general  agreement  within  the  defense  systems 
acquisition  community  that  the  acquisition  process  takes  too 
long.  In  1978  Dr.  William  J.  Perry,  then  Director  of 
Defense  Research  and  Engineering,  said,  'the  single  biggest 
deficiency  in  our  acquisition  program  is  the  ridiculously 
long  acquisition  time'"  (1:3).  For  example,  even  over  the 
relatively  short  time  span  of  a  decade,  acquisition  lead 
times  have  increased  dramatically  as  documented  in  the 
following  table: 

Aerospace  Increasing  Lead  Time 


ITEM  FROM  TO 


Year 

Weeks 

Year 

Weeks 

Forgings,  Titanium 

1972 

25 

1980 

1  50 

Castings,  Aluminum 

1972 

10 

1980 

52 

Landing  Gear 

1973 

50 

1980 

1  20 

Integrated  Circuits 

1  972 

12 

1980 

59 

Engines,  Aircraft 

1  977 

82 

1980 

162 

Airframes 

1977 

95 

1980 

198 

(25:1-4) 

"It  used  to  take  from  five  to  seven  years  to  acquire  a 
weapon  system,  but  now  takes  between  12  and  15  years  oefore 
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a  system  is  deployed  in  the  field"  (19:47).  This  increase 
in  the  time  required  for  military  acquisition  is  especially 
significant  "since  the  acquisition  cycle  for  commercial 
aircraft  has  not  lengthened  significantly  during  the  past 
two  decades"  (13:21).  "Today's  modern  commercial  aircraft, 
such  as  Boeing's  747  and  757  are  as  complex  as  many  of  the 
defense  systems  the  (military)  services  acquire"  (1:4),  and 
yet,  "...the  time  from  conception  to  initial  delivery  is 
about  8  years"  (1:4).  The  Defense  Science  Board  1977  Summer 
Study  pointed  out  that  the  commercial  sector  achieves  this 
short  acquisition  time  through  phase  compression,  also 
called  concurrency  (13:28).  Maj  David  Spencer,  in  examining 
tne  reasons  for  the  military's  increase  in  weapon  acquis¬ 
ition  time,  also  identified  concurrency  as  a  key  factor: 
"production  times  have  increased  significantly  oecause  of 
program  stretch-outs  caused  by  excessive  testing,  government 
funding  constraints,  and  reduced  concurrency"  (52:36). 


Backg  round 

The  term  concurrency  "which  evolved  in  the  late  1950s 
on  the  Air  Force  Ballistic  Missile  Program,  involved  the 
initiation  of  some  of  the  production  activities  on  a  program 
prior  to  completion  of  the  full-scale  development  effort" 
(2:38).  However,  the  term  has  expanded  to  even  "being  used 
to  describe  the  situation  when  a  simulator  or  other  aircrew 
training  devices  are  required  for  delivery  at  tne  same  time 
as  tne  new  aircraft  it  will  support"  (8:118).  Currently, 


tne  primary  interpretations  of  this  acquisition  term  are: 
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1)  parallel  (back-up)  technological  development, 

2)  simultaneous,  but  independent,  technological 
development  and  testing, 

3)  co-production,  and 

4)  overlap  of  dependent,  normally  sequential 
activities.  (26:11-2) 

For  the  purpose  of  this  study,  concurrency  is  defined  as  an 
acquisition  strategy  involving  overlap  of  normally  sequen¬ 
tial  weapon  acquisition  phases,  especially  between  Full 
Scale  Development  (FSD)  and  production,  to  achieve  an 
earlier  operational  capability  for  a  weapon  system. 

Although  concurrency  is  identified  as  a  key  factor  for 

reducing  overall  procurement  time,  its  use  has  sparked 

controversy  since  the  1960s.  The  Blue  Ribbon  Defense  Panel 

in  its  1970  Report  to  the  President  and  tne  Secretary  of 

Defense  recommended  "a  general  rule  against  concurrent 

development  and  production  efforts"  (15:8).  However,  seven 

years  later,  the  Defense  Science  Board  stated:  "assuming 

the  intent  to  deploy  clearly  exists  at  the  start  of  FSD, 

concurrency  is  highly  desirable"  (13:51).  Recently,  this 

controversy  has  resurfaced. 

The  scuttling  of  DIVAD  is  being  interpreted  in 
some  quarters  as  sounding  the  death  knell  for 
concurrency — the  intentional  overlapping  of 
development  and  production  of  weapon  systems. 

DIVAD  failed,  some  say,  because  concurrency 
failed .  (19:47) 


Problem  Statement 


Although  short  articles  have  been  published  wnich  pro¬ 
vide  elementary  summaries  of  this  acquisition  strategy's 
history,  no  one  has  yet  produced  a  study  detailing  both  the 
successes  and  failures  of  concurrent  acquisition,  and  more 
importantly,  the  fundamental  management  principles  which 
lead  to  a  successful  concurrent  acquisition.  For  example, 
while  concurrency  is  now  employed  as  standard  practice  in 
many  Air  Force  acquisition  programs,  the  opinions  of  mana¬ 
gers  currently  implementing  this  strategy  are  undocumented. 

Scope  of  Research 

I  propose  to  study  the  history  of  concurrency  in  United 
States  military  acquisition.  I  also  intend  to  interview 
managers  in  the  Air  Force  Aeronautical  Systems  Division 
\ ASD )  acquisition  programs  concerning  the  current  implemen¬ 
tation  of  concurrency  within  ASD.  The  Aeronautical  Systems 
Division  is  the  primary  division  within  Air  Force  Systems 
Command  (AFSC)  using  concurrency  in  Air  Force  acquisition. 
Although  the  Ballistic  Missile  Office  has  two  weapon  pro¬ 
grams  both  large  and  urgent  enough  to  warrant  the  use  of 
concurrency,  both  programs  (the  Peacekeeper  and  the  Midget- 
man),  have  been  beset  by  special  Congressional  constraints 
which  have  interfered  with  program  scneduling  to  the  extent 
that  they  could  prejudice  my  research  findings.  The  Elec¬ 
tronic  Systems  Division  and  the  Armament  Division  do  not 
provide  feasible  candidates  for  concurrency  research  since 
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they  generally  face  the  constraint  of  providing  systems 
which  must  feed  into  the  total  systems  that  the  Aeronautical 
Systems  Division  manages.  I  feel  it  will  be  most  productive 
to  interview  managers  who  are  involved  in  these  top  level 
concurrent  programs. 

Research  Questions 

While  analyzing  the  past  history  of  United  State's 
military  application  of  concurrency,  I  intend  to  ask  the 
following  questions: 

1.  Why  was  concurrency  originally  employed  in  the  Air  Force 
Ballistic  Missile  Program? 

2.  Why  was  the  initial  use  of  concurrency  so  effective? 

3.  Why  was  concurrency  blamed  for  cost  overruns  in  the 
1960s? 

4.  Why  did  the  Defense  Science  Board  advocate  the  use  of 
concurrency  in  weapon  system  acquisition? 

5.  Has  the  employment  of  concurrency  changed  since  the 
concept  was  originated  in  the  1950s? 

While  interviewing  managers  involved  in  concurrent 
acquisition  programs,  I  will  seek  to  answer  the  following 
questions: 

6.  How  is  concurrency  employed  in  today's  Air  Force 
acquisition  programs? 

7.  How  does  concurrency  affect  acquisition  programs? 

8.  What  factors  can  reduce  the  acquisition  risk  of 
concurrency? 

9.  What  do  managers  actually  involved  in  concurrent 
programs  think  about  the  strategy? 


II.  Research  Methodology 


Data  Collection 

This  thesis  involved  two  distinct  research  phases.  In 
the  first  phase,  the  researcher  conducted  a  literature 
review  of  concurrency  from  its  conception  in  the  Air  Force 
Ballistic  Missile  Program  to  the  present.  However,  as  the 
literature  review  progressed,  it  became  apparent  that  the 
term  "concurrency",  which  originated  in  the  late  1950s,  was 
simply  a  new  terminology  for  management  principles  applied 
in  earlier  accelerated  weapon  acquisition  programs — known  as 
"crash"  programs.  Therefore,  the  literature  review  was 
expanded  to  include  these  programs. 

The  second  phase  involved  interviewing  managers  working 
in  the  Aeronautical  Systems  Division  at  Wr ight-Pattarson  AFB 
(primarily  Program  Managers  and  Deputy  Program  Managers), 
who  are  currently  involved  in  acquisition  programs  employing 
concurrency.  In  order  to  select  a  representative  cross- 
section  of  ASD  managers  who  were  involved  in  concurrent 
programs,  the  researcher  met  with  Lt  Col  Balvin,  the  ASD 
Acquisition  Management  Staff  Officer,  who  recommended 
specific  managers  to  contact  in  a  variety  of  ASD  Programs. 
Each  manager  recommended  by  Lt  Col  Balvin  had  an  unique 
perspective  on  the  use  of  concurrency  and  was  involved  with 
at  least  one  concurrent  acquisition  program. 


Literature  Review 


The  researcher  attempted  to  investigate  all  references 
to  the  use  of  concurrency  in  acquisition  program  management, 
and  also  articles  referring  in  some  way  to  the  length  of  the 
acquisition  process.  Many  articles  concerning  the  length  of 
the  acquisition  process  also  discussed  the  strategy  of  con¬ 
currency.  In  addition,  the  researcher  reviewed  sources  of 
information  concerning  the  United  State's  early  ballistic 
missile  programs  since  the  acknowledged  use  of  concurrency 
was  initiated  in  these  missile  programs.  The  researcher 
also  searched  Congressional  Records  for  references  concern¬ 
ing  the  use  of  concurrency  in  past  military  acquisition 
programs . 

The  Instrument 

It  was  necessary  to  use  interviews  rather  than  surveys 
because  the  use  of  concurrency  was  unique  for  every  program 
application.  In  addition,  since  there  is  no  formal  or 
"accepted"  definition  of  concurrency,  different  managers  had 
different  concepts  of  what  concurrency  entailed.  In  order 
to  react  to  these  possibilities,  the  researcher  arranged 
face-to-face  interviews  with  managers  who  were  involved  in 
concurrent  programs  to  retain  maximum  flexibility  for  fol¬ 
lowing  up  on  innovative  concurrency  approaches. 


Construction  of  Interview  Questions 

The  interview  questions  were  designed  to  allow  concise 
answers.  The  questions  avoided  a  simple  yes  or  no  answer  as 
much  as  possible  to  give  the  Program  Manager  an  opportunity 
to  explain  the  reasoning  behind  his  answers.  These  ques¬ 
tions  evolved  during  the  course  of  the  interview  schedule  as 
the  researcher  gained  additional  insignt  on  the  current 
implementation  of  concurrency.  The  fourteen  initial 
measurement  questions  are  listed  below: 

1.  What  other  acquisition  programs  were  you  involved  with 
that  were  concurrent? 

2.  Before  your  current  assignment,  what  was  your  general 
assessment  of  the  usefulness  of  concurrency? 

3.  Has  your  opinion  changed  because  of  your  present 
experience?  In  what  ways? 

4.  What  was  the  initial  assessment  of  the  primary  areas  of 
acquisition  risk  on  your  program?  Cost,  schedule, 
performance,  or  supportability?] 

5.  Was  your  current  use  of  concurrency  planned  from  the 
start  of  the  program?  If  not,  why  was  it  employed? 

6.  What  has  been  the  schedule  affect  of  concurrency  on 
your  program? 

7.  What  has  been  the  cost  effect? 

8.  What  are  the  primary  benefits  of  concurrency? 

9.  What  are  the  primary  drawbacks  of  concurrency? 

10.  Did  concurrency  force  an  earlier  freeze  of  design  than 
you  would  have  planned  otherwise?  Is  this  a  benefit? 

11.  What  factors  contribute  to  effective  use  of 
concurrency? 

12.  What  factors  hinder  effective  use  of  concurrency? 

13.  Have  you  employed  concurrency  in  any  ways  you  would 


consider  unique?  What  were  these? 

14.  If  you  had  it  to  do  over  again,  what  would  you  change 
about  your  program's  use  of  concurrency? 

As  the  interviews  progressed,  the  researcher  found  some 

measurement  questions  of  dubious  value.  Consequently,  only 

eight  measurement  questions  appear  in  the  Findings  section. 

The  final  list  of  eight  questions  appears  below: 

1.  Why  do  acquisition  programs  use  concurrency? 

2.  What  advantages  can  concurrency  produce? 

3.  What  disadvantages  can  concurrency  produce? 

4.  How  can  the  risk  of  concurrency  be  reduced? 

5.  How  do  contractors  feel  about  the  use  of  concurrency? 

6.  How  do  the  using  commands  feel  about  the  use  of 
concurrency? 

7.  Should  Interim  Contractor  Support  (ICS)  be  employed  on  a 
concurrent  program? 

8.  What  are  the  manager's  overall  appraisals  of 
concurrency? 

Interview  Managers 

The  researcher  arranged  non-attributable,  face-to-face 
interviews  which  were  limited  to  1/2  hour.  To  allow  a  flow¬ 
ing  discussion  and  obtain  the  maximum  amount  of  information 
possible,  the  researcher  tape-recorded  these  interviews  and 
subsequently  produced  a  transcript  of  each  interview.  The 
20  ASD  managers  who  were  interviewed  are  listed  below: 

Mr.  L.  Benavides  Directorate  of  Logistics  Policy  and 

Programs,  Acquisition  Logistics 

Col  T.  Berle  Deputy  Commander  for  Acquisition 

Logistics 
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Col  H.  Bevelhymer 


Lt  Col  W.  Cosnowski 


|  Col  B.  Crane 

I 

|  Lt  Col  V.  Dellamea 

i 

t 


Mr.  D.  Eastman 


i  Col  H.  Edwards 

I 

i 


Col  R.  French 

Mr.  J.  Graves 

Mr.  B.  Harlan 

Col  J.  Nauseef 

Mr.  H.  Peot 

Mr.  R.  Reis 
Lt  Col  C.  Rigano 

Lt  Col  R.  Robinson 


Program  Manager,  Air  Launched 
Strategic  Missile  System  Program 
Office,  Strategic  Systems 

Deputy  Director,  Directorate  of 
Engineering,  Airlift  and  Trainer 
Systems 

Deputy  Commander  for  Strategic 
Systems 

Program  Manager,  F/FB-111  Modern¬ 
ization  System  Program  Office, 
Strategic  Systems 

Deputy  Director,  T-46A  System 
Program  Office,  Airlift  and 
Trainer  Systems 

Directorate  of  Program  Control, 
Strategic  Systems 

Directorate  of  Program  Control, 
Tactical  Systems 

Deputy  Director,  Advanced  Tactical 
Fighter  System  Program  Office, 
Tactical  Systems 

Deputy  Director,  Strike  Systems 
System  Program  Office,  Recon/Strike 
and  Electronic  Warfare  Systems 

Directorate  of  Program  Control,  F-16 
System  Program  Office 

Assistant  System  Program  Director, 
Bl-B  System  Program  Office 

Manager,  Missile  Contracts  Division, 
Strategic  Systems 

Deputy  Director,  Ground  Launched 
Cruise  Missile  System  Program 
Office,  Strategic  Systems 

Program  Manager,  SRAM  II  Missile 
Division,  Strategic  Systems 


Col  R.  Shearer 


Program  Manager,  AGM-65  (Maverick) 
System  Program  Office,  Tactical 
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Systems 


Mr.  J.  Singer  Program  Manager,  Rescue/Special 

Operations,  Airlift  and  Trainer 
Systems 

!  Mr.  F.  Tuck  Deputy  Director,  Subsystems/Support 

Equipment  System  Program  Office, 
Aeronautical  Equipment 

Col  J.  Verstreate  Program  Manager,  Fighter/ Attack 

System  Program  Office,  Tactical 
Systems 

Data  Analysis 

j  While  the  first  phase  of  this  research  was  important  to 

establish  a  historical  background  for  understanding  concur¬ 
rency,  the  second  phase  of  the  research  (interviews  with 

J  various  ASD  managers),  provides  candid  opinions  of  managers 

actually  involved  with  concurrent  programs.  The  researcher 
has  provided  excerpts  of  these  interviews  in  Appendices  A 
through  H.  Because  the  interview  questions  evolved  during 
the  interview  process,  not  all  of  the  managers  responded  to 
all  of  the  questions;  and,  in  some  cases,  they  chose  not  to 
respond.  However,  if  an  opinion  was  expressed,  it  does  ap- 

| 

j  pear  verbatim  in  the  Appendix  unless  specific  program  refer¬ 

ences  were  made  (these  were  eliminated).  Random  numbers 
were  assigned  to  each  manager  quoted  in  the  appendix,  but 
the  numbering  sequence  was  applied  consistently  throughout 
all  eight  appendices.  Therefore,  each  time  a  particular 
numbered  manager  is  referenced  in  each  appendix,  it  is  the 
same  individual  who  responds. 

1  1 


III.  Findings 


Concurrency  and  the  Air  Force  Ballistic  Missile  Program 

Description  of  Concurrency .  The  term,  "concurrency" 
was  first  coined  by  Maj  Gen  Barnard  Schriever  in  early  1958. 
As  Commander  of  the  Air  Force  Ballistic  Missile  Division, 

Gen  Schriever  nad  been  tasked  to  "develop  a  ballistic  mis¬ 
sile  capable  of  carrying  a  thermonuclear  warhead  to  inter¬ 
continental  rangas--namely  the  Atlas"  (46:53).  However, 
unlike  previous  peacetime  procurements,  this  project  was  a 
race  against  the  clock  to  beat  the  Soviet  Union  in  producing 
the  first  intercontinental  ballistic  missile  (ICBM).  To 
achieve  this  goal,  innovative  management  practices  were 
applied  and  a  new  term,  concurrency,  was  devised  to  describe 
this  new  approach. 

According  to  Maj  Gen  Ritland,  in  a  1960  Air  University 

Quarterly  Review  article  entitled  "Concurrency",  this  new 

acquisition  strategy  required, 

...an  overlapping  of  the  development  functions  so 
that,  for  instance,  flight  test  can  proceed  coin¬ 
cident  with  production,  construction  can  get  under 
way  while  flight  test  is  in  progress,  and  training 
can  be  initiated  concurrently  with  testing  and 
production.  (45:238) 

As  Gen  Schriever  described  it: 

Our  unique  management  concept  has  enabled  us  to 
effectively  pursue  many  important  tasks  simul- 
taneously--a  necessary  prerequisite  for  an  accel¬ 
erated  program  sucn  as  ours,  which  is  involved  in 
extending  frontiers  of  knowledge,  and  at  tne  cur¬ 
rent  state  of  the  art  to  the  problem  of  achieving 
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operational  capability  at  the  earliest  possible 
date.  (48:68) 

Concurrency/  as  described  in  the  two  previous  para¬ 
graphs,  amounted  to  a  total  weapon  system  acquisition  con¬ 
cept  (an  idea  still  evolving  during  the  1950s),  operating 
under  a  restrictive  compressed  program  schedule  which,  in 
turn,  was  driven  by  a  compelling  threat  to  national  secur¬ 
ity.  While  the  idea  of  total  system  planning  is  routine 
management  practice  today,  conventional  military  acquisition 
during  that  period  still  followed  a  policy  better  suited  to 
the  simpler  weapon  designs  of  the  pre-World  War  II  period: 

The  old  concept,  safe,  sure,  and  terribly  slow, 
consisted  of  a  lengthy  period  of  research  and 
development,  followed  by  component  testing,  the 
building  of  as  few  as  one  prototype,  exhaustive 
testing  of  the  prototype,  and  finally,  if  every¬ 
thing  worked,  a  production  order.  Tooling  alone 
often  took  enough  time  for  the  gradual  phasing  in 
of  personnel,  bases,  support  equipment,  and  logis¬ 
tic  backup.  (34:86) 

Therefore,  the  concurrency  strategy  was  a  new  total  system 
philosophy  of  acquisition  better  suited  to  both  rapidly 
advancing  military  technology  and  the  growing  Soviet  threat: 
characteristics  which  marked  the  decade  of  the  1950s.  To 
understand  how  this  management  concept  came  about,  it  is 
first  necessary  to  understand  the  roots  of  the  United  States 
ballistic  missile  program. 

Ballistic  Mi ssile  Technical  Foundations .  This  effort 
had  its  beginnings  in  the  closing  days  of  World  War  II,  when 
the  German  V-2  rockets,  capable  of  Mach  4  speeds,  proved  the 
conceptual  validity  of  the  ballistic  missile  concept.  As  an 


aside,  the  V-2  program  was  itself  concurrent  since  "the  Ger¬ 
mans  put  the  V-2  ballistic  missile  into  production  so  early 
that  more  than  65,000  engineering  orders  were  subsequently 
needed  to  make  it  operational"  (41:5).  The  Germans  produced 
about  6,000  V-2s  during  the  war,  and  although  highly  inaccu¬ 
rate  and  limited  to  a  one  ton  TNT  warhead,  the  advent  of 
nuclear  warheads  provided  the  U.S.  with  a  new  incentive  to 
explore  this  technology  (34:85).  In  the  aftermath  of  the 
war,  U.S.  Army  intelligence  teams  gathered  both  German  tech¬ 
nical  information  and  top  scientists  (such  as  Werner  von 
Braun)  togetner.  After  assessing  the  German  V-1  and  V-2 
programs,  as  well  as  many  other  *  systems  which  never  reached 
production  (including  the  A-9/A-10  two-stage  rocket,  a  true 
intercontinental  ballistic  missile  with  a  range  of  3,000 
miles  which  would  have  allowed  Germany  to  strike  coastal 
cities  of  the  United  States),  twenty  eight  missile  studies 
were  initiated  by  the  Air  Force  (17:139).  One  of  these 
projects  was  a  1946  systems  study  contract  awarded  to  Con- 
solidated-Vultee  (later  renamed  Convair),  called  Project  MX- 
774,  a  forerunner  of  the  Atlas  program. 

Ballistic  Mi ssile  Technical  Ku rdles .  At  this  time,  the 
ballistic  missile  concept  still  faced  three  major  technical 
hurdles:  the  atomic  warhead  was  too  large  and  heavy  to  be 

propelled  thousands  of  miles  by  existing  rocket  engines; 
ballistic  missile  guidance  systems  were  inaccurate;  plus, 
nosecone  materials  were  unable  to  survive  the  extreme  tern- 


perature  of  re-entry,  due  to  these  drawbacks,  the  simpler 
technology  of  air-breathing  missiles  with  their  proven  meth¬ 
ods  of  propulsion  and  guidance  received  a  higher  priority 
and  MX-774  fell  victim  to  a  reduced  Air  Force  budget  the 
next  year. 

Because  Convair  was  convinced  of  the  project's  merit, 
it  kept  the  program  alive  with  its  own  development  funds 
(34:85).  This  decision  was  rewarded  in  1951,  when  the  Air 
Force  resurrected  MX-774  (although  it  was  renamed  Project 
1593)  by  awarding  Convair  a  second  contract.  It  was  at  this 
point  that  the  code  name  "Atlas"  was  assigned  to  the  project 
(54:30).  The  project  could  have  faced  a  second  death  if  not 
for  the  "thermonuclear  breakthrough  of  1952"  which  revolu¬ 
tionized  the  existing  state  of  the  art  in  nuclear  theory. 

This  made  it  possible  to  package  a  hydrogen  bomb 
in  a  bundle  small  enough  to  fit  into  a  missile 
nose  cone.  Thus,  both  the  stringent  accuracy 
requirement  and  the  extremely  high  propulsion 
requirement  were  simultaneously  eliminated.  The 
thermonuclear  breakthrough  brought  the  development 
of  an  intercontinental  ballistic  missile  well 
within  the  range  of  the  existing  state  of  the  art, 
which  would  make  the  resulting  weapon  both  mili¬ 
tarily  desirable  and  technically  feasible.  (34:85) 

Following  this  key  advancement  of  technology,  the  intercon¬ 
tinental  ballistic  missile  concept  began  to  attract  addi¬ 
tional  advocates  within  the  Department  of  Defense.  Prompted 
by  mounting  fears  of  a  potential  "missile  gap",  the  Depart¬ 
ment  of  Defense'  guided  missiles  study  group  of  the  Armed 
Forces  Policy  Council,  in  1953,  recommended  a  high  level 
study  of  strategic  missile  programs  by  a  special  blue  ribbon 
committee  of  the  nation's  leading  scientists  (49:7). 


To  perform  this  evaluation,  Mr.  Trevor  Gardner, 
then  Air  Force  Special  Assistant  for  Research  and 
Development,  established  the  Air  Force  Strategic 
Missiles  Evaluation  Committee  (SMEC),  also  known 
as  the  'Teapot'  committee.  (49:7) 

The  Ne umann  Commi ttee .  According  to  Robert  Perry’s 
study  of  the  USAF  Ballistic  Missile  Program,  the  SMEC  was 
formed  for  the  ostensible  purpose  of  achieving  defense  bud¬ 
get  savings  by  recommending  cucoacks  in  the  total  missile 
development  program;  however,  the  committee  also  made  recom¬ 
mendations  which  redirected  the  United  States'  nuclear 
retaliatory  strategy  (42:60).  Tne  SMEC  was  chaired  by  Prof. 
Jonn  von  Neumann,  a  renowned  scientist  of  the  Princeton 
Institute  for  Advanced  Study,  and  composed  of  eleven  other 
eminent  scientists--includ ing  several  who  had  been  involved 
in  the  Manhattan  Project  (47:55).  The  concurrency  concept 
and  the  innovative  foundation  of  the  Air  Force  Ballistic 
Missile  Program,  actually  stems  from  recommendations  made  by 
Dr.  Neumann's  committee.  They  recommended  that  the  Air 
Force  should  proceed  with  the  crash  development  of  an  inter¬ 
continental  Ballistic  missile.  To  snorten  the  program's 
development  time  they  drew  upon  lessons  from  the  Manhattan 
Project  and  made  three  primary  recommendations: 

(a)  The  participation  jointly  by  private  research 
laboratories  and  industrial  firms  in  the  conduct 
of  development  projects. 

(o)  The  setting  up  of  a  semi -autonomous  agency 
with  tne  full  responsibility  for  the  day-to-day 
supervision  of  a  development  project. 


(c)  The  adoption  of  concurrent  scheduling  whereby 
different  pnases  of  the  development  programme  were 
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|  undertaken  simultaneously  rather  than  sequentially 

as  had  been  done  in  the  past.  (5:64) 

Certainly  the  most  important  recommendation  to  counter  the 

projected  Soviet  ballistic  missile  threat  was  the  recogni- 

J  tion  that  the  intercontinental  ballistic  missile  must  be 

i 

developed,  from  the  beginning  of  the  program,  by  a  special 
concurrent  strategy  rather  than  the  conventional  peacetime 
process.  While  some  concurrency  did  already  exist  in  acqui¬ 
sition  programs  at  this  time, 

...most  of  it  occurred  as  the  result  of  an  exped¬ 
ient  to  gain  time  after  the  programme  had  already 
slipped  in  arrears,  and  so  was  neither  properly 
planned  or  executed.  The  concept  of  concurrency 
proposed  by  the  Strategic  Missiles  Evaluation 
Committee  was  radical  both  in  the  extent  of  the 
overlap  envisaged  and  in  the  fact  that  it  should 
follow  a  closely  laid  comprehensive  plan.  (5:65) 

Ballistic  Missile  Program  Initiation.  In  May  1954, 
the  Secretary  of  the  Air  Force  adopted  the  "Teapot"  commit¬ 
tee's  recommendations  and  directed  the  acceleration  of  the 
Atlas  program.  He  also  assigned  the  program  the  top  prior¬ 
ity  in  the  Air  Force.  Whereas  the  Manhattan  Project  cost 
the  nation  a  total  of  $2  billion,  the  Air  Force  ballistic 
missile  program  would  soon  cost  over  a  billion  dollars  per 
year  during  the  program's  development  and  production 
(48:68).  Most  important  of  all,  in  keeping  with  the  commit¬ 
tee's  second  recommendation,  "The  Air  Research  and  Develop¬ 
ment  Command  was  directed  to  establish  an  organization  in 
the  field  which  would  exercise  overall  responsibility  and 
authority  for  the  program"  (47:55).  Just  three  months  lat- 
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er,  the  Western  Development  Division  of  Headquarters  ARDC 
(later  renamed  the  Ballistic  Missile  Division),  was  estab¬ 
lished  in  Inglewood,  California  (49:8).  This  autonomous 
organization , 

"was  to  have  responsibility  and  authority  over  all 
aspects  of  the  program  with  the  specific  purpose 
of  reorienting  and  accelerating  the  ICBM  program 
in  order  to  achieve  the  earliest  possible  opera¬ 
tional  capability"  (47:55). 

Ballistic  Missile  P r oq r am  Description.  The  Air  Force 
Ballistic  Missile  Program  was  a  single  development  effort 
from  which  three  missile  configurations  would  emerge:  the 
Atlas,  the  Titan,  and  the  Thor.  This  approach  allowed  key 
technologies  to  be  transfer'red  between  subsystems,  espe¬ 
cially  the  propulsion  guidance  and  the  nose  cone  (47:56). 

The  first  missile  in  the  program  was  tne  Atlas;  more  sophis¬ 
ticated  was  the  Titan,  which  had  a  more  powerful  second 
stage  type  design.  An  intermediate  range  ballistic  missile, 
the  Tnor,  a  single  stage  design,  was  designed  for  deployment 
in  Europe.  Through  the  use  of  concurrency,  "only  eleven 
months  after  BMD  got  the  go-ahead  from  the  Department  of 
Defense,  the  first  Thor  missile  came  off  the  production 
line"  (34:86).  Even  more  significant,  the  program  set  a 
goal  of  "...December  1958  as  tne  date  for  the  first  Thor 
operational  squadron  to  be  ready  for  shipment  overseas" 
(34:86).  That  was  just  three  years  after  the  project  began. 

Ballistic  Mi ssile  Program*  s  Special  Status .  Integrally 
linked  to  the  concept  of  concurrency,  the  Air  Force  Bai- 


listic  Missile  Program  was  planned  to  be  an  "exempt"  or 
"special"  program.  This  action  entailed  removing  an 
extremely  important  program  away  from  Wright  Field — an 
unpopular  action  with  both  the  Air  Staff  and  the  Air 
Research  and  Development  Command;  as  the  program  progressed, 
there  were  repeated  attempts  to  bring  this  "exempt"  program 
back  within  the  Wright  Field  "fold"  (42:62). 

Brig  Gen  Bernard  Schriever,  who  later  was  appointed  as 
AFSC's  first  Commander,  was  assigned  to  command  the  WDD  and 
manage  the  ballistic  missile  program.  The  urgency  of  the 
project  was  highlighted  by  Operation  Castle,  conducted  from 
March  through  May  of  that  year  at  the  Pacific  Proving 
Ground.  These  tests  proved  the  previous  theoretical  feasi¬ 
bility  of  developing  high  yield  thermonuclear  warheads  that 
could  meet  the  size  and  weight  constraints  of  an  ICBM 
(54:81 ) . 

Key  Management  Principles .  There  were  a  number  of 
successful  management  practices  which  the  Air  Force  Ballis¬ 
tic  Missile  Program  initiated  for  the  first  time  on  a  peace¬ 
time  military  procurement  (in  many  respects,  these  manage¬ 
ment  principles  paralleled  those  employed  on  the  Manhattan 
Project).  However,  contrary  to  most  published  articles  of 
that  era,  the  most  important  management  principle  was  not 
simply  the  use  of  concurrency  or  schedule  compression. 

While  concurrency  is  an  integral  (and  highly  publicized) 
part  of  this  overall  concept,  the  second  recommendation  of 


the  Neumann  Committee — a  semi-autonomous  organization  with 
full  responsibility  to  administer  the  concurrent  program — 
was  the  key  to  the  ballistic  missile  program's  success.  As 
was  discovered  during  the  1960s,  reliance  on  simple  program 
schedule  compression  without  a  special  organization  to 
administer  it,  will  only  increase  the  overall  acquisition 
risk  of  a  program.  The  characteristics  of  this  special 
organization  were  outlined  by  Gen  Schriever  in  the  form  of 
five  key  management  guidelines: 

1.  Maximum  decentralization; 

2.  Minimum  committee  operation; 

3.  Maximum  priority; 

4.  Minimum  red  tape; 

5.  Authority  to  go  with  responsibility.  (33:32) 

Within  these  overall  guidelines,  tne  Ballistic  Missile 
Program  instituted  several  management  practices  which 
reduced  the  risKs  which  attend  concurrent  efforts. 

Human  Re  sources .  Gen  Schriever  gathered  a  small, 
nighly  skilled  development  team  together.  In  his  article 
"Ballistic  Missiles  and  Management,"  Gen  Schriever  claimed 
that  his  technical  staff  at  WDD  were  hand-picked  and  highly 
qualified.  In  fact,  more  than  one-third  had  eitner  Ph.D's 
and  Master  Degrees  in  a  time  when  those  degrees  were  much 
less  common  than  today  (47:56).  Also,  many  of  his  personnel 
nad  already  been  involved  on  other  Air  Force  Missile  pro¬ 
jects.  While  Gen  Schriever  empnasized  top  quality  person¬ 
nel,  he  kept  his  organization  manning  lean: 


Relatively  few  individuals  were  assigned  to  the 
program  offices  through  the  first  five  years  of 
the  ballistic  missile  program.  The  expeditious¬ 
ness  of  decision  making  and  the  readiness  of  com¬ 
munication  at  that  level  were  enhanced  thereby. 

(42:76) 

In  fact,  by  June  1957,  only  46  personnel  were  assigned  to 
the  program  offices  (42:76). 

Program  Autonomy.  To  the  greatest  extent  possi¬ 
ble,  the  ballistic  missile  program  sought  to  operate  autono¬ 
mously  from  Wright  Field  and  intermediate  levels  of  over¬ 
sight.  The  Ballistic  Missile  Program  had  its  own  contracts 
office,  headed  by  Brig  Gen  Ben  Funk,  which  exercised  "con¬ 
tracting  and  procurement  responsibility  for  the  entire  pro¬ 
gram"  (47:56).  Consequently,  "in  most  cases  the  entire 
process  from  the  statement  of  job  requirements  through  to 
the  notification  of  contractor  selection  took  place  within 
ninety  days"  (49:13).  Even  then,  no  time  was  lost  negoti¬ 
ating  contracts  since  contractors  were  authorized  to  immedi¬ 
ately  begin  work  with  letter  contracts  until  the  formal  con¬ 
tracts  were  definitized  (49:13).  This  office  also  had  spe¬ 
cial  plant  representatives  who  answered  directly  to  Gen  Funk 
in  all  of  the  contractor  plants  involved  in  the  Ballistic 
Missile  Program  (47:56).  These  representatives  supervised 
and  expedited  "all  actions  involved  in  the  implementation  of 
program  contractual  requirements"  (47:56). 

Autonomy  was  also  maintained  through  the  use  of  special 


security  measures. 


Even  wnen  external  pressures  and  the  need  for  less 
restrictive  security  protocols  made  it  impossible 
to  invest  the  entire  program  with  such  exclusive¬ 
ness  l the  top  secret  designation],  much  of  the 
atmosphere  of  a  closed  society  was  preserved  by 
rigorous  enforcement  of  a  "need  to  know"  secrecy 
standard  that  was  only  casually  honored  elsewhere. 
(42:70) 

Since  the  program  was  not  autonomous  in  regard  to  funding, 
the  security  shield  that  protected  the  program  from  outside 
tinkering  was  breached  through  this  avenue.  An  attempt  was 
made  by  Trevor  Gardner  to  arrange  a  separate  financial  ac¬ 
count  for  the  program;  this  proposal  required  approval  by  a 
committee  composed  of  representatives  from  the  Air  Staff, 
the  Air  Material  Command,  and  the  Air  Research  and  Develop¬ 
ment  Command,  but  it  was  rejected  (42:71).  As  a  result, 
contracts  in  excess  of  $350,000  still  required  the  multiple 
approvals  customary  of  conventional  programs  (42:72).  This 
action  exposed  the  program  to  additional  red  tape: 

Anyone  charged  with  any  aspect  of  funding  review 
could  argue  tnat  he  had  to  know  the  purpose  of 
every  expenditure.  Knowing  the  purpose  and  having 
the  authority  for  funds  approval,  he  was  in  a 
position  to  influence  the  program.  (42:72) 

Although  the  program  was  unable  to  achieve  complete  autonomy 
from  intermediate  levels  of  oversight,  the  measure  of  inde¬ 
pendence  which  Gen  Scnriever  was  able  to  achieve  allowed 
decisive  decision  making  generally  free  from  time  consuming 
second  guessing  at  higher  levels. 

Technical  Support  Staf f .  Another  key  management 
decision  was  to  "retain  overall  system  responsibility  and 
contract  for  a  technical  and  scientific  staff"  (49:3).  By 
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contracting  for  the  services  of  the  Guided  Missile  Research 
Division  of  the  Ramo-Wooldr idge  Corporation,  the  ballistic 
missile  program  gained  invaluable  scientific  and  technical 
talent  as  well  as  proven  systems  engineering  skills  to  man¬ 
age  this  complex  program.  Tnrough  this  stratagem,  the  pro¬ 
gram  also  avoided  "the  salary  and  environmental  strictures 
of  civil  service  by  creating  a  technically  talented  special- 
status  corporation  and  endowing  it  with  exceptional  operat¬ 
ing  latitude"  (42:67).  It  also  bears  repeating  that  using 
an  elite  engineering  group  allowed  the  program  to  maintain 
its  independence  from  Wright  Field. 

Competitive  Focus.  Because  of  the  funding  prior¬ 
ity  assigned  to  the  ballistic  missile  program,  Gen  Schriever 
was  able  to  adopt  " . .  .a  two  pronged  philosophy  of  competi¬ 
tion — competition  among  contractors  and  alternative  (not 
parallel)  technical  approaches"  (47:56).  Taking  a  page  from 
the  Manhattan  Project,  Schriever  did  not  rely  on  one  best 
way,  but  pursued  at  least  one  alternate  approach  for  each 
key  technology  which  had  to  be  "pushed."  "It  was  felt  that 
such  a  philosophy  would  accomplish  an  end  result  sooner, 
better,  and  in  the  end  cheaper,  as  well  as  provide  the 
optimum  technical  backup"  (47:56).  This  statement  was  borne 
out  by  Robert  Perry  study  of  the  ballistic  missile  program; 
he  concluded:  "a  deliberate  policy  of  parallel  and  tandem 
development  at  the  component  and  subsystem  level  provides  a 
greater  assurance  of  success  than  any  other  alternative" 
(42:133). 
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Limited  Decision  Chain.  Finally,  the  program's 
decision-making  process  was  expedited.  As  Lt  Gen  Irvine 
wrote  in  a  1958  Air  Force  Magazine  article,  "Programs  come 
directly  from  the  project  office  at  the  Ballistic  Missile 
Division  through  the  Air  Staff  to  the  Secretary  of  the  Air 
Force,  and  then  directly  to  the  Secretary  of  Defense  for 
final  decision"  (27:53). 

Flight  Test  Principles .  Related  to  specific  concurrent 
policy  was  the  flight  test  strategy  Gen  Schriever  developed. 
This  strategy  was  based  upon  four  fundamental  principles: 

1.  No  dead-end  testing. 

2.  Ground  test  whenever  possible.  (34:86) 

3.  All  testing  is  done  at  the  lowest  possible 
level . 

4.  Flight  test  results  are  utilized  to  the 
maximum.  (46:54) 

No  Dead-End  Testing .  This  first  principle  "...is 
an  outgrowth  of  the  concurrency  concept  and  means  that  no 
component  is  tested  except  in  the  configuration  in  which  it 
will  appear  in  the  production  version  of  the  missile" 
(34:86).  This  meant  "components  are  fabricated  on  produc¬ 
tion  lines,  using  production  drawing  and  tooling"  (46:54). 

By  utilizing  this  principle,  a  manufacturing  learning  curve 
was  established  much  earlier,  and  the  experience  was  direct¬ 
ly  applicable  to  the  final  production  version.  This  doesn't 
mean  that  all  of  the  equipment  of  the  final  version  of  the 
missile  was  on  beard  for  the  flight  test,  but  it  was  put 
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together  in  the  same  configuration  as  the  final  production 
version.  This  idea  also  made  flight  test  results  directly 
applicable  to  the  actual  production  missile.  The  only 
exception  to  this  rule  was  the  Lockheed  X-17  missile.  As 
stated  earlier,  a  key  technical  hurdle  to  be  overcome  was 
the  development  of  a  missile  nose  cone  that  could  survive 
intense  re-entry  temperatures.  "This  re-entry  test  vehicle 
proved  to  be  a  quick  and  accurate  way  to  gain  reliable  data 
without  flying  a  full-scale  missile"  (49:17).  So,  in  key 
technical  areas  which  require  a  significant  advancement  of 
the  state  of  the  art,  special  test  vehicles  may  be 
warranted . 

Ground  Test .  The  second  principle  was  for  reasons 
of  economics.  Since  these  missiles  could  only  be  launched 
once  and  flight  test  information  (especially  at  that  time), 
is  limited,  ground  test  was  essential. 

Component  Testing .  The  third  principle  describes 

a  pyramiding  process.  As  Maj  Gen  Ritland  wrote: 

The  suppliers  of  the  smallest  parts — and  there  are 
hundreds  of  thousands  of  parts  in  any  ballistic 
missile  weapon  system — test  each  and  every  part 
intensively.  These  parts  are  then  furnished  to 
subcontractors,  who  combine  them  into  components 
or  subsystems.  These  in  turn  are  vigorously 
tested.  Subsystems  are  integrated  into  systems, 
and  the  systems  are  checked  out  under  simulated 
environmental  testing  conditions.  Next,  the  en¬ 
tire  missile  is  static-tested.  Ultimately  the 
"bird"  itself  proves  the  compatibility  of  all  its 
elements  by  the  highest  measuring  device  of  all, 
flight  test.  (45:246) 


This  concept  limited  the  overall  number  of  expensive  flight 
tests,  and  identified  earlier  in  the  life  cycle,  any  sub¬ 
system  problems. 

Flight  Test  Data  Utilization.  The  final  concept 
recognized  that  ground  test  could  not  fully  simulate  prob¬ 
lems  that  occur  in  free  flight,  but  because  of  the  expense 
of  flight  test,  the  greatest  amount  of  usable  data  is 
extracted  from  every  test: 

The  test  objectives  of  a  given  flight  frequently 
include  the  acquisition  of  data  needed  for  more 
than  one  our  three  ballistic  missiles.  For  exam¬ 
ple,  Thor  flights  have  carried,  as  part  of  tneir 
instrumentation,  equipment  that  will  be  used  in 
the  Titan  guidance  system.  (46:56) 

Comparison  of  Missile  Programs .  Thus  far,  special 
emphasis  has  been  placed  on  the  "exempt"  acquisition  status 
of  the  ballistic  missile  program.  To  provide  additional 
insight  into  the  potential  advantages  of  this  strategy,  it 
is  necessary  to  compare  the  ballistic  missile  program  to  a 
conventional  weapons  procurement  of  that  period.  Fortun¬ 
ately,  two  excellent  examples  exist:  the  Snark  and  Navaho 
cruise  missile  programs. 

While  the  Atlas,  Thor,  and  Titan  ballistic  missile  pro¬ 
grams  proved  extremely  successful,  the  Snark  and  the  Navaho 
cruise  missile  programs  faced  continued  failure  until  they 
were  ignorainously  canceled.  Despite  the  dramatic  contrast 
in  end  achievement,  a  comparison  between  the  programs  is 


warranted  because. 


They  were  in  development  daring  the  same  period, 
they  had  similar  operational  requirements  (indeed, 
they  stemmed  from  the  same  requirement),  and  they 
were  not  greatly  different  in  complexity  of  tech¬ 
nology.  (42:1) 

But  the  development  philosophies  were  completely  different: 

...the  cruise  missiles  were  developed  in  accord¬ 
ance  with  prevalent  ground  rules  and  within  an 
existing  establishment,  whereas  the  ballistic 
missiles  had  a  special  and  exempt  status;  and  in 
general  the  urgency  of  ballistic  missile  develop¬ 
ment  exceeded  that  of  the  cruise  missiles.  (42:1) 

Cruise  Missile  Program  Flaws .  There  were  three  primary 

flaws  in  the  management  of  the  cruise  missile  programs  as 

compared  to  the  ballistic  missile  program.  First,  technical 

alternatives  for  high  risk  subsystems  were  not  pursued; 

second,  concurrency  was  applied  incorrectly;  and  third,  lack 

of  a  special  status — which  hindered  management  flexibility. 

Alternative  Technical  Approaches.  One  of  the 
greatest  realized  dangers  the  two  cruise  missile  programs 
encountered  was  the  underestimation  of  the  technical  diffi¬ 
culties  to  be  overcome.  The  idea  of  a  "flying  torpedo"  was 
not  new.  The  cruise  missile  concept  had  existed  within  the 
United  States  since  1917  with  a  small  robot  aircraft  project 
that  had  continued  in  development  until  1932  (42:23).  The 
German  use  of  the  V-1  rocket  during  World  War  II  attracted 
new  interest  in  the  concept;  before  the  end  of  the  war,  the 
United  States  had  produced  more  tnan  1300  J3-2s — our  copy  of 
the  V-1.  Development  continued  uninterrupted  on  various 
cruise  missile  concepts  after  the  war,  so  by  1951,  when  both 
the  Snark  and  Nava ho  development  projects  were  underway,  a 


false  confidence  concerning  perceived  technical  hurdles 
existed  within  the  two  programs.  And  unlike  the  ballistic 
missile  program,  the  cruise  missile  programs  followed 
conventional  acquisition  management  practice  and  alternative 
technical  approaches  were  not  pursued.  This  short-sighted 
action  produced  the  following  result: 


...because  of  the  absence  of  feasible  alterna¬ 
tives,  it  was  virtually  impossible  to  change  the 
course  of  the  program  once  it  was  underway.  When 
technology  proved  stubborn  the  developers  had  no 
choice  but  to  try  to  bend  it  to  their  will;  it 
would  not  readily  bend,  causing  many  bf  the  diffi¬ 
culties  the  cruise  missiles  encountered  during 
development.  (42:137) 

Misuse  of  Concurrency .  While  the  ballistic 
missile  program  planned  to  use  concurrency  from  the  initi¬ 
ation  of  the  program,  unplanned  schedule  compression  was 
used  extensively  on  both  the  Snark  and  Navaho  programs 
(42:35,45);  but  using  concurrency  in  that  manner  was  totally 
unsuccessful.  Scheduled  milestones  continued  to  slip,  with 
the  result  that  the  Snark  was  "completed"  six  years  behind 
schedule,  and  the  Navaho  slipped  three  years  before  its 
demise  (42:116).  If  any  conclusion  can  be  drawn  from  these 
two  cruise  missile  programs,  it  is  that  accelerating  a 
problem-ridden  program  contributes  to  program  failure. 


Limited  Manag erne at  Flexibility .  Finally,  tne 


ballistic  missile  program  enjoyed  an  exempt  program  status — 


shielded  from  outside  interference — while  the  cruise  missile 


programs  were  developed  within  the  conventional  acquisition 


environment.  This  exposed  tne  Snark  and  Navaho  programs  to 


28 


the  instability  at  Wright  Field  (including  three  reorganiza- 


tions  in  five  years  within  the  the  Weapons  System  Division), 
as  well  as  political  struggles  between  various  divisions  and 
commands  (42:22,52-53).  As  a  result  of  having  to  manage 
programs  within  this  highly  unstable  yet  highly  structured 
environment,  both  cruise  missile  programs  lacked  the  flexi¬ 
bility  to  resolve  the  inevitable  program  failures: 

Far  more  than  Atlas,  Thor,  or  Titan,  the  Snark  and 
Navaho  programs  were  conducted  in  accordance  with 
plans  laid  down  early.  The  only  notable  flexibil¬ 
ity  in  either  program  was  in  its  accommodation  of 
schedule  changes  that  arose  in  slippages,  over¬ 
runs,  and  failures  to  solve  technical  problems. 

(42:117) 

Ballistic  Mi ssile  Technical  Achievements .  Perhaps  the 
most  tailing  difference  between  the  two  approaches  were  the 
final  results  the  autonomous  ballistic  missile  program 
achieved.  The  Strategic  Missiles  Evaluation  Committee 
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originally  outlined  the  following  performance  goals  for  the 
Atlas  program: 

[they)  believed  a  weapon  could  be  built  to 
operational  status  in  six  to  eight  years;  that 
such  a  weapon  could  have  a  circular  error  of 
probability,  or  accuracy  radius,  of  about  five 
miles;  and  that  it  could  deliver  a  nuclear  payload 
of  a  specified  yield  to  a  target  5500  nautical 
miles  away.  (45:241) 

Through  the  use  of  a  concurrent  acquisition  strategy  and  the 
special  management  practices  initiated  during  the  program, 
the  Atlas  ICBM  became  operational  in  five  years  and  its  Cir¬ 
cular  Error  Probable  (CE?)  was  conservatively  estimated  at 
two  miles.  In  addition,  both  the  yield  of  the  nuclear  war- 
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head  and  tne  range  of  the  missile  exceeded  the  original 
committee  specification.  In  contrast,  both  the  Snark  and 
the  Navaho  were  ultimately  canceled. 

Fact  Versus  Legend .  Despite  Gen  Schriever's  enthusiasm 
for  "concurrency",  it  is  necessary  to  recognize  that  this 
specific  term  was  devised  late  in  the  ballistic  missile 
program.  Throughout  the  development,  the  flight  test  prin¬ 
ciples  utilized  were  common  sense  ideas  which  recognized 
that  testing  inefficiency  was  not  compatible  with  a  highly 
compressed  schedule.  In  the  case  of  the  missile  nose  cone, 
no  one  asked  whether  a  special  test  vehicle  was  compatible 
with  the  use  of  concurrency;  it  was  simply  recognized  that  a 
high  technical  risk  existed  and  tne  X-17  missile  was  the 
most  direct  way  to  reduce  the  risk.  Consequently,  rather 
than  thrashing  out  a  restrictive  definition  of  what  concur¬ 
rency  entailed,  the  independent  ballistic  missile  program 
office  ignored  the  question  entirely  and  concentrated  on 
solving  problems.  This  philosophy  appears  to  be  the  hall¬ 
mark  of  the  Air  Force  Ballistic  Missile  Program — a  small, 
caiented,  and  autonomous  group  of  highly  motivated  Air  Force 
and  contractor  personnel  were  allowed  to  concentrate  on  the 
development  of  a  highly  capaole  weapon  system  chrough  what¬ 
ever  methods  offered  the  most  promise.  The  Lockheed  Skunk 
Works  is  a  similar  example  of  the  potential  advantages  of 
such  an  acquisition  strategy  which  will  be  explored  in  the 
following  section. 
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Crash  Programs 

The  Depth  Charge  Program.  Although  the  term  "concur¬ 
rency"  was  not  coined  until  1958,  the  concept  of  concur¬ 
rency,  better  known  as  the  "crash"  program,  existed  long 
before.  A  crash  program  was  even  used  successfully  shortly 
before  World  War  I  to  produce  the  top  secret  weapon,  the 
"depth  charge."  In  1917: 

Elmer  Sperry,  Jr.,  rushed  to  Washington,  where  he 
and  his  naval  counterpart,  Lt.  Wilkinson,  met  with 
Admiral  Earle,  who  told  them  to  get  together  'and 
build  some  of  tnese  depth  charges  in  a  hell  of  a 
hurry."  When  they  asked  what  depth  charges  looked 
like,  he  replied,  "I  don't  know;  go  find  out!' 

(63:15) 

Before  four  months  had  passed  following  that  meeting,  Sperry 
had  already  produced  over  500  depth  charges  (63:15). 


Crash 


Principles .  As  typified  by  the  depth 


charge  program,  a  crash  program  normally  requires  the 
following  factors  for  success: 

1.  A  significant  threat  demanding  rapid  response; 

2.  great  latitude  in  managing  the  crash  program; 

3.  unrestricted  resources  to  draw  upon;  and 

4.  very  close  cooperation  between  the  Program 
Office  and  highly  motivated  contractors. 

The  key  principle  is  the  existence  of  a  significant  threat, 

since  this  drives  the  other  three  factors  and  provides  the 

foundation  for  the  basic  directive  to  get  it  done  "in  a  hell 

of  a  nurry."  Until  the  Cold  War,  crash  programs  were 

restricted  to  periods  of  war  since  the  United  States  was 


SwWnw 


sheltered  between  two  oceans  from  perceived  enemies.  Be¬ 
tween  World  War  I  and  World  War  II,  weapon  system  develop¬ 
ment  centered  on  the  sequential  strategy  of  "design  it, 
build  it,  test  it,  and  produce  it"  (3:5).  The  advent  of 
World  War  II  once  again  ushered  in  an  adequate  threat  to 
drive  the  use  of  concurrency.  As  Mr.  Robert  Gibson  of 
Lockheed  wrote: 

In  periods  of  national  emergency,  the  question  of 
concurrent  or  overlapping  phases  of  development, 
production,  testing  and  logistic  support  is  not 
raised.  It  is  when  we  think  we  have  the  luxury  of 
time  that  the  issue  is  raised.  (20:181) 

Conventional  Crash  Programs .  There  were  two  types  of 
crash  programs  during  World  War  II:  the  acquisitions  of 
conventional  weapon  systems  such  as  fighter  and  bomber  air¬ 
craft,  and  the  first  "mega-program" — the  Manhattan  Project. 
The  World  War  II  conventional  crash  programs  began  on  16  May 
1940,  when  President  Franklin  D.  Roosevelt,  in  response  to 
the  escalating  war  in  Europe,  issued  a  call  for  50,000  mili¬ 
tary  aircraft  to  be  produced  (62:1).  To  achieve  this  goal 
(in  the  end  176,458  aircraft  were  produced),  significant 
compression  of  typical  aircraft  development  times  was 
required  since  "...only  four  (C-47,  B-17,  A-20,  and  P-40)  of 
the  IS  major  models  of  aircraft  used  in  World  War  II  had 
achieved  production  status  as  of  June  1940"  (62:1). 
Production  and  testing  proceeded  concurrently,  and  often 
required  significant  modification  of  equipment  that  had 
already  reached  the  field.  The  P-47  is  a  good  example  of 
the  potential  problems  of  using  this  approach: 


The  first  experimental  prototype  was  built  and 
flown  in  May  1941,  only  ten  months  after  initial 
design  work  was  started.  (62:2) 

Because  flight  testing  generated  additional  design  changes, 

The  first  several  hundred  airplanes  were  restrict¬ 
ed  to  non-combat  use.  Not  until  1943  was  the  P-47 
used  by  a  combat  squadron  over  Europe.  (62:2) 

So  despite  the  method's  inefficiencies,  just  three  years 
after  design  work  was  begun,  the  U.S.  Army  Air  Corps  had 
hundreds  of  P-47s  ready  for  use  in  Europe. 

The  operational  utility  of  new  aircraft  was  not  ade¬ 
quately  tested  prior  to  operational  deployment,  and  "signif¬ 
icant  changes  were  made  throughout  the  war  on  all  models" 
(62:1);  that  even  includes  the  four  models  already  in  pro¬ 
duction.  Therefore,  not  all  of  the  rework  activity  can  be 
blamed  on  a  concurrent  strategy,  but  it  was  a  primary  con¬ 
tributor  to  the  retrofit  problems  encountered  during  the 
period.  But  in  a  time  of  national  emergency,  the  nation  was 
willing  to  accept  less  efficiency  to  achieve  greater  wartime 
capability  at  the  earliest  possible  date. 

Crash  Program  Lessons .  Out  of  these  conventional  crash 
programs,  there  were  some  lessons  that  remain  applicable  in 
the  present  acquisition  environment. 

Turnover  of  Key  Personnel .  The  rapid  turnover  of 
Army  and  Navy  officers  assigned  to  manage  these  crash 
programs  created  a  perpetual  knowledge  gap  that  hindered 
effective  management: 

When  a  new  officer  became  resident  representative 
or  the  head  of  a  project,  the  company  executives 
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would  have  to  spend  time  in  explaining  just  what 
was  taking  place.  In  many  instances/  the  diffi¬ 
culty  was  increased  by  the  officer's  lack  of  know¬ 
ledge  of  aircraft  manufacture.  Frequently  an  off¬ 
icer  would  be  transferred  just  as  he  became  well 
acquainted  with  his  duties.  For  instance,  six 
different  project  officers  were  in  charge  of  one 
Army  model  during  the  two  years  of  its  development 
and  initial  production.  (32:66) 

Micro-Management.  Contractors  were  forced  to  deal 
with  a  confused  assortment  of  government  departments,  agen¬ 
cies,  and  bureaus.  Often,  the  presidents  of  the  companies 
developing  the  aircraft  were  forced  to  abdicate  their  man¬ 
agement  responsibilities  because  so  much  of  their  time  was 
monopolized  by  various  government  groups  (32:66).  Obviously 
this  violates  the  concept  of  great  management  latitude  and 
it  is  likely  that  tne  programs  suffered  some  of  their  later 
retrofit  problems  as  a  result.  In  addition,  these  govern¬ 
ment  agencies  often  dealt  with  trivial  details  best  left  to 
the  contractor. 

Time  could  probably  have  been  saved  if  government 
agencies  had  judged  the  aircraft  companies  more  on 
their  overall  performance  and  less  on  highly  de¬ 
tailed  standards  and  specifications.  There  may  be 
some  significance  to  the  fact  that  two  of  the 
fastest  developments  of  Array  planes — the  North 
American  P-51  and  the  Lockheed  P-80 — the  designers 
were  net  required  to  check  details  with  the 
government.  (32:66) 

It  should  also  be  noted  that  the  P-51  was  arguably  the  best 
long-range  fighter  aircraft  the  United  States  produced 
during  the  war. 

Human  Resource  Toll .  Finally,  the  crash  program 


program  extracts  a  large  toll  on  human  resources: 


In  every  company  visited,  instances  were  cited  of 
key  men  who  had  to  leave  their  positions  perman¬ 
ently  or  temporarily  because  of  nervous  breakdowns 
and  other  illnesses  brought  on  by  long  hours  and 
constant  stress.  The  Lockheed  engineers  broke 
records  for  speed  when  they  designed  the  P-80,  but 
at  the  end  of  the  period  they  had  a  sickness  rate 
of  30%.  (32:67) 

As  we  will  see,  the  Manhattan  Project  was  freed  of  many  of 
these  limitations  and  became  a  hallmark  of  effective  man¬ 
agement  as  a  result. 

The  Manhattan  Project .  The  Manhattan  Project  came 
about  in  reaction  to  the  suspected  development  of  an  atomic 
bomb  by  the  Germans.  As  it  turned  out,  this  assessment  was 
incorrect,  but  nevertheless,  this  fear  drove  the  development 
of  nuclear  fission  by  the  United  States  and  Great  Britain. 
"The  Germans,  it  was  felt,  must  surely  be  investigating  in 
tneir  orderly  and  determined  way,  the  possibility  of  obtain¬ 
ing  a  weapon  of  such  decisive  value"  (10:29).  This  sense  of 
danger  was  greatly  magnified  snortly  after  the  Germans  over¬ 
ran  Denmark.  Niels  Bohr,  a  Danish  physicist  who  had  formu¬ 
lated  the  theory  of  the  nuclear  atom,  sent  a  mysterious 
telegram  to  Dr.  Otto  Frisch,  an  eminent  physicist  who  was 
involved  in  Britain’s  newly  established  nuclear  program. 

The  telegram  contained  a  number  of  personal  messages,  but 
concluded  with  the  words,  "TELL  COCKCROFT  AND  MAUD  RAY  KENT” 
(10:76-77).  Since  on  the  face  of  it,  no  sense  could  be  made 
of  this  message,  it  was  assumed  Bohr  had  sent  a  coded  mes¬ 
sage  of  great  import.  Cockcroft  was  a  scientist  involved  in 
some  of  Britain's  most  secret  research  so  it  was  believed 
the  words  MAUD  RAY  KENT  held  the  key. 


It  was  then,  judging  by  Thomson's  description  of 
the  incident  many  years  later,  that  the  author¬ 
ities,  Doth  scientific  and  military,  began  to  sur¬ 
pass  themselves  in  ingenuity.  For  it  was  only 
necessary  to  transpose  an  * i *  for  tne  1 y'  in  the 
penultimate  word  and  MACJD  RAY  KENT  became  an  ana¬ 
gram — of  the  words  'radium  taken.'  Surely  here 
was  proof,  if  proof  were  still  needed,  that  the 
Germans  were  moving  fast  in  the  race  for  the 
atomic  bomb.  (10:77) 

As  luck  would  have  it,  "MAUD"  was  assumed  to  refer  to  the 
top  secret  M.A.U.D.  committee  (Military  Applications  of 
Uranium  Detonation),  whose  job  was  to  determine  the  possi¬ 
bility  of  developing  and  producing  an  atomic  bomb  for  the 
British  war  effort  (10:58).  After  the  war  was  concluded,  it 
turned  out  that  the  telegram  was  purely  personal,  but  had 
been  garbled  in  transmission.  Dr.  Bohr  had  simply  wanted 
his  messages  passed  on  to  nis  friend  Dr.  Cockcroft  and  his 
former  governess,  a  Miss  Maud  Ray,  who  was  living  in  Kent  at 
that  time.  Nevertheless,  this  message  accentuated  fears  of 
a  German  atomic  bomb  and  an  overriding  threat  was  estab¬ 
lished  which  spurred  the  use  of  concurrency. 

Tne  German  Nuclear  Effort.  As  an  aside,  the 
German  nuclear  effort  was  a  comedy  of  errors  until  the  end 
of  the  war.  While  important  progress  nad  been  made  up  to 
1940,  a  serious  error  was  made  in  1941  which  sidetracked  the 
entire  German  nuclear  effort.  Because  of  apparent  impuri¬ 
ties,  the  Germans  concluded  that  pure  graphite  was  not  a 
satisfactory  pile  moderator  (28:85).  due  to  this  error 
(which  was  not  independently  verified),  the  entire  German 
research  effort  was  limited  to  a  small  and  unreliable  supply 
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of  heavy  water  from  Norway.  This  episode  hignlights  one  of 
che  most  serious  mistakes  committed  by  the  Germans  on  their 
atomic  program:  no  central  project  office  was  established 
with  the  broad  mandate  to  create  an  atomic  bomb  and  verify 
research  results.  Attempts  were  made  by  German  scientists 
to  develop  this  mandate,  but  administrative  errors  doomed 
their  efforts.  One  attempt  to  create  interest  on  the  part 
of  top  leaders  such  as  Speer,  Himmler,  Goring,  and  others 
failed  because  of  a  secretary's  mistake.  These  leaders  were 
supposed  to  be  invited  to  a  short  seminar  discussing  nuclear 
weapon  potential: 

instead  of  the  agenda  listing  eight  brief  popular 
talks,  headed  by  one  by  Professor  Schumann  on 
'Nuclear  Physics  as  a  Weapon,'  and  including  ten- 
minute  speeches  by  Hahn,  Heisenberg,  Bothe, 

Geiger,  Clasius,  Hurteck,  and  Esau,  many  of  the 
guests — including  Himmler— were  accidently  sent 
the  long  list  of  highly  complex  scientific  papers 
to  be  read  over  three  days  in  the  related  confer¬ 
ence  at  the  Kaiser-Wilhelm  Institute.  (28:106) 

All  top  level  leaders  turned  down  the  invitation  and  Germany 

lost  its  last  chance  to  regain  its  early  lead  in  nuclear 

research.  Consequently, 

the  status  of  the  German  effort  at  the  close  of 
the  war  in  Europe  was  reminiscent  of  the  early 
phases  of  our  project  in  the  United  States,  when 
committees  were  appointed  only  to  be  superceded  by 
other  committees.  At  times  it  seemed  as  though 
more  thought  had  to  be  devoted  to  organization 
than  to  solving  the  problems  under  study.  (22:245) 

Overall,  the  German  nuclear  effort  reflected  the  whole¬ 
sale  violation  of  the  crash  program  factors  for  success. 
Besides  lacking  an  autonomous  program  office,  the  German's 


believed  in  their  own  scientific  prowess  to  such  a  degree, 
they  never  seriously  considered  the  threat  of  the  United 


States  or  Britain  developing  an  atomic  bomb.  Therefore, 

German  nuclear  research  received  a  low  priority  and  both 

management  latitude  and  funding  was  restricted  (although 

much  of  this  was  due  to  the  German  scientist's  own  timidity 

in  requesting  support) .  Finally,  many  German  scientists 

seemed  to  lack  the  necessary  motivation: 

there  was  continual  bickering,  as  might  be  expect¬ 
ed,  over  supplies  and  material,  and  surprisingly 
enough,  in  tne  light  of  most  American  scientist's 
pleas  for  freedom  from  the  restrictions  of  com- 
partmentalization,  there  was  a  generally  non- 
. cooperative  attitude  regarding  the  exchange  of 
information  Detween  various  groups.  Many  German 
scientists  worked  alone  on  their  individual  pro¬ 
jects  and  did  not  seem  to  feel  any  compulsion  to 
work  for  the  national  interest.  (28:245) 

Manhattan  Project  Management  Principles .  In 
contrast  to  the  unsuccessful  German  effort,  the  United 


States  Manhattan  Project  incorporated  the  concurrent  or 
crash  program  principles.  As  previously  mentioned,  it  was 
assumed  tne  Germans  were  mounting  a  major  effort  to  develop 
an  atomic  bomb.  Therefore,  the  threat  was  firmly  estab¬ 
lished.  Second,  the  Manhattan  Project  was  granted  tremen¬ 
dous  management  latitude — certainly  unequaled  in  the  history 
of  the  United  States.  Even  tne  existence  of  tne  program, 
wnich  eventually  cost  approximately  $23  out  of  the  total 
$1Q0B  war  effort,  was  kept  secret  from  all  but  a  handful  of 
Congressmen,  and  even  the  Vice  President  of  the  United 
States  was  not  told,  due  to  this  great  freedom  from  detail- 


ed  oversight/  Groves  instituted  revolutionary  concurrent 
practices  which  predate  the  Air  Force  Ballistic  Missile 
Program: 

We  then  had  to  design,  build  and  operate  an 
extremely  large  plant  of  incredible  complexity, 
without  the  benefit  of  any  pilot  plant  for  this 
process.  Always  we  were  driven  by  tne  need  to 
make  haste.  Consequently,  research,  development, 
construction  and  operation  all  had  to  be  started 
and  carried  on  simultaneously  and  without  apprec¬ 
iable  prior  knowledge.  (22:95-96) 

He  was  able  to  follow  this  strategy  because  the  program  had 

access  to  resources  that  for  all  intents,  were  unlimited. 

This  is  best  illustrated  in  a  passage  from  Gen  Groves  book, 

"Now  It  Can  Be  Told": 

The  only  time  I  thought  that  tnere  might  be  some 
question  raised  about  the  work  came  after  our  re¬ 
turn  to  Wasnington.  As  I  was  saying  good-by  to 
them  at  the  airport.  Congressman  Taber,  who  had 
long  been  renowned  for  his  interest  in  keeping 
down  government  expenditures,  said:  'General, 
will  you  come  over  nere  for  a  minute — I  want  to 
ask  you  a  question.'  My  first  thought  was: 

'Well,  here  it  comes,'  and  so  I  was  utterly  as¬ 
tounded  when  Mr.  Taber  said:  'There  is  only  one 
thing  that  worries  me.  General.  Are  you  sure  that 
you  are  spending  enough  money  at  Oak  Ridge?' 
(22:364-365) 

Access  to  unlimited  resources  included  people  resources  as 
well:  close  to  600,000  people  were  eventually  involved  in 

support  of  the  Manhattan  Project  (22:414).  Just  as  an 
example,  when  a  mining  expert  with  extensive  linguistic 
ability  was  sought  by  the  program,  over  a  million  personnel 
records  were  reviewed  to  find  tne  most  qualified  candidate. 
Finally,  the  Manhattan  Project  employed  highly  motivated 
contractors.  So  highly  motivated,  in  fact,  that  Du  Pont 
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refused  tne  first  letter  of  intent  offered  them  because  it 

contained  the  standard  clause  that  the  contractor  would 

receive  a  fixed  fee  in  addition  to  reimbursement  for  costs 

(22:53).  To  satisfy  legal  requirements,  Du  Pont  nad  to 

settle  for  a  fee  of  one  dollar.  Of  course,  even  crash 

programs  can't  escape  the  bureaucracy  completely: 

Although  the  expected  duration  of  the  contract  was 
stated,  as  is  usual,  soon  after  V-J  Day  Du  Pont 
was  paid  tne  entire  fee  of  one  dollar.  This  re¬ 
sulted  in  a  disallowance  by  government  auditors, 
since  the  entire  time  of  the  contract  had  not  run 
our.  Consequently,  Du  Pont  was  asxed  to  return 
thirty-three  cents  to  tne  United  States.  Fortun¬ 
ately,  the  officers  of  Du  Pont  nad  retained  tneir 
sense  of  humor  throughout  their  many  years  of 
association  with  the  government,  and  were  able  to 
derive  considerable  amusement  from  this  ruling. 

(22:59) 

The  nee  result  of  this  program  were  the  successful  atomic 
blasts  at  Hiroshima  and  Nagasaki  which  caused  Japan  to 
capitulate  without  an  invasion  of  the  Japanese  mainland, 
which  would  nave  caused  far  greater  loss  of  life  on  both 
sides.  The  use  of  concurrency  allowed  tne  timely  use  of  the 
atomic  bomb  although  as  Maj  Gen  Groves  concluded:  "not 
until  later  would  it  become  accepted  practice  to  proceed 
vigorously  on  major  phases  of  the  work  despite  large  gaps  in 
oasic  knowledge"  (22:11). 

Post-War  Acquisition .  In  post-war  America,  except  for 
tne  ballistic  missile  program,  which  followed  tne  classic 
crasn  program  principles,  military  weapon  acquisition  fell 
bacx  into  a  conventional  sequential  pattern.  Many  acquisi¬ 
tion  programs  fell  victim  to  the  common  desire  to  continu- 
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ally  incorporate  rapidly  advancing  technology  into  the 
weapon  system: 

Despite  outstanding  successes  in  Terrier,  Sparrow, 
and  Nike  development  test  firings,  production  was 
not  initiated  because  the  developers  could  see 
continued  improvement  in  the  future.  They  failed, 
however,  to  realize  the  tremendous  advantages 
which  would  nave  accrued  by  placing  these  systems 
into  production.  (40:476) 

However,  some  overlap  of  development  and  production  did 
occur;  tnis  was  the  concept  of  "accelerated  testing"  where 
the  initial  aircraft  production  was  tested  operationally. 
"Defects  found  in  these  early  aircraft  were  corrected  in 
later  production  models  and/or  modifications  programs  were 
set  up  to  correct  all  airplanes  produced  before  the  defect 
was  discovered"  (62:5).  Sometimes  this  resulted  in  a  large 
number  of  aircraft  produced  before  modifications  were  intro¬ 
duced  to  correct  the  defects.  "For  example,  459  F-102A  air¬ 
craft  (nearly  one-half  of  the  total  produced)  were  delivered 
without  adequate  fire  control  systems,  requiring  extensive 
and  time  consuming  modification"  (62:14).  during  the  Phase 
Testing  concept  prevalent  in  the  1950’s, 

the  common  result  of  sucn  a  teeter-totter  approach 
was  delayed  production  schedules  (the  F-84F  sched¬ 
ule  slipped  two  years)  or  delivery  of  aircraft 
which  had  to  be  returned  to  the  contractor  for 
modification.  Tne  B-47  was  a  classic  example.  As 
it  was  produced  it  moved  directly  from  the  produc¬ 
tion  line  to  the  modification  line.  (62:15) 

Because  of  these  consequences,  the  "Cook-Cragie"  concept  was 
initiated  in  the  mid-1950s.  Named  after  the  Air  Force  gen¬ 
erals  who  implemented  it,  this  idea  restricted  production 
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for  13-24  months  until  testing  was  completed  (62:15).  This 
limited  the  risk  of  concurrent  acquisition  to  tne  period  of 
low-rate  production. 

Tne  Lockheed  Skunk  Works .  Another  form  of  concurrency, 
which  predated  Gen  Schriever's  concept,  became  known  as  the 
"Skunk  Works"  concept.  "Kelly"  Johnson's  Skunk  Works  was  a 
autonomous  design  office  composed  of  a  highly  motivated  and 
capable  group  of  engineers.  Overall  manning  of  the  office 
was  Kept  approximately  one  fourth  the  size  of  a  conventional 
design  department.  Yet  this  group  has  produced  some  of  the 
United  States'  most  brilliant  aircraft  designs  in  less  than 
one  half  the  normal  development  time  of  other  aircraft  manu¬ 
facturers  . 

Prig ination  of  the  Skunk  Works.  The  idea  origi¬ 
nated  at  Lockheed  Aircraft  during  World  War  II.  The  first 
American  jet  fighter,  the  P-59  aircraft,  was  built  by  Bell 
Aircraft  in  1943,  but  its  performance  offered  little  advan¬ 
tage  over  existing  piston-powered  aircraft  such  as  the  P-33 
and  P-51  (4:30).  Following  this  disappointment,  the  Army 
Air  Corps  invited  "Kelly"  Johnson  to  design  a  jet  fighter 
based  on  the  de  Havilland  Goblin  engine  since  they  concluded 
Lockheed's  own  innovative  engine  design  would  not  be  com¬ 
pleted  in  time  (29:96). 

An  extremely  tight  schedule  of  180  days  was  estab¬ 
lished  for  design,  build,  and  delivery  of  the 
first  Snooting  Star.  Despite  this,  at  its  peak 
che  XP-80  project  had  only  23  engineers  and  105 
snoo  men  wno  worked  long  hours  in  absolute  secrecy 
in  a  temporary  building  near  Lockheed ' s  first  wind 
cunnel .  (24:  37) 
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Although  Kelly  Jonnson  faced  a  program  schedule  considered 
almost  impossible  to  satisfy,  with  only  23  engineers 
"stolen"  from  other  projects  to  design  the  aircraft,  on  day 
143,  the  Army  Air  Corps  accepted  the  first  P-80  jet  aircraft 
for  flignt  test — beating  the  highly  compressed  schedule  by 
37  days  (29:99).  This  impromptu  organization  did  not  dis¬ 
band  following  the  P-80  project;  "tne  Skunk  Works  operated 
until  the  early  1950s  in  a  similar  role  to  that  of  most  air¬ 
frame  manufacturers  experimental  departments"  (24:134).  For 
instance,  using  the  management  pattern  established  on  the 
P-80  project,  Kelly  Johnson's  engineering  team  designed  and 
flew  the  F-104  jet  fignter  just  a  year  and  a  day  after  pro¬ 
ject  initiation  (29:110).  However,  "following  the  assign¬ 
ment  to  develop  the  hignly  secret  U-2  aircraft,  the  Skunk 
Works  nas  operated,  more  or  less,  as  an  autonomous  unit, 
complete  with  its  own  manufacturing  facilities"  (24:134). 

The  U-2  Project .  For  the  U-2  project,  Kelly 

Johnson  proposed  to  "...build  20  airplanes  with  spares  for 

roughly  $22  million  and  have  the  first  one  flying  within 

eight  months"  (29:121).  According  to  Mr.  Johnson, 

the  government  got  a  bargain  on  that  contract  wnen 
completed — about  $2  million  in  refunds  on  contract 
costs,  and  six  extra  airplanes  from  spare  parts  we 
didn't  need  because  the  U-2  functioned  so  well. 

(29:124) 

In  addition,  the  schedule  was  also  achieved;  Mr.  Johnson  had 
made  nis  proposal  in  late  1953,  development  began  in  the 
Spring,  and  on  4  August,  1955,  during  what  was  supposed  to 
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be  just  a  taxi  test,  the  plane,  due  to  its  "powered  glider" 
design,  lifted  off  the  ground  and  flew  for  the  first  time 
(29:121,125). 

The  SR-7 1  Project .  Of  course,  the  SR-71  aircraft 
is  the  best  Known  of  the  Skunk  Works  innovative  aerospace 
products.  The  SR-71  aircraft  came  about  through  the  "A" 
series  of  design  studies  Lockheed  conducted  in  the  late 
1950s: 

in  1958  and  1959,  Kelly  Johnson  had  made  a  series 
of  proposals  for  Mach  3-plus  reconnaissance  air¬ 
craft  to  the  CIA  and  the  Air  Force.  The  Skunk 
Works  design  numbers  were  A-1  through  A-12;  they 
all  nad  at  least  two  engines,  a  cruising  altitude 
over  80,000  feet,  and  a  very  low  radar  cross  sec¬ 
tion  over  a  wide  band  of  frequencies.  (24:136) 

The  A-12  design  was  declared  the  winner  of  a  secret  paper 
study  competition  on  29  August,  1959,  and  a  limited  develop¬ 
ment  approval  was  given  followed  by  a  full  production 
approval  for  "design,  manufacture,  and  test  of  12  aircrafc" 
(29:136).  Despite  having  to  invent  virtually  every  system 
and  subsystem  within  the  aircraft,  "tne  first  flight  of  the 
A-12  took  place  on  26  April,  1962,  chirty  months  after  the 
limited  go-ahead  in  September  1959  (24:136). 

Skunk  Works  Management  Principles .  While  the 

superlative  results  of  tne  Lockheed  Skunk  Works  are  well 

known,  the  specific  management  principles  which  led  to  these 

results  have  not  been  so  well  publicized.  Kelly  Johnson's 

14  "points"  are  listed  below: 

I .  The  Skunk  Works  manager  must  be  delegated 
practically  complete  control  of  his  program  in  all 
aspects . 
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2.  Strong  but  small  project  offices  must  be 
provided  both  by  the  military  and  industry. 

3.  Tne  number  of  people  having  any  connection 
with  the  project  must  be  restricted  in  an  almost 
vicious  manner. 

4.  A  very  simple  drawing  and  drawing  release 
system  with  great  flexibility  for  making  changes 
must  be  provided. 

5.  There  must  be  a  minimum  number  of  reports 
required,  but  important  work  must  be  recorded 
thoroughly. 

6.  There  must  be  a  monthly  cost  review  covering 
not  only  what  has  been  spent  and  committed  but 
also  projected  costs  to  the  conclusion  of  tne 
program. 

7.  The  contractor  must  be  delegated  and  must 
assume  more  than  normal  responsibility  to  get  good 
vendor  bids  for  subcontractor  work  on  the  project. 

8.  Push  more  inspection  responsibility  back  to 
subcontractors  and  vendors.  Don't  duplicate  so 
much  inspection. 

9.  Tne  contractor  must  be  delegated  the  authority 
to  test  his  final  product  in  flight.  He  can  and 
must  test  it  in  the  initial  stages.  If  he 
doesn't,  he  rapidly  loses  his  competency  to  design 
other  vehicles. 

10.  The  specifications  applying  to  the  hardware 
must  be  agreed  to  in  advance  of  contracting. 

11.  Funding  a  program  must  be  timely  so  that  the 
contractor  doesn't  have  to  keep  running  to  the 
bank  to  support  government  projects. 

12.  There  must  be  mutual  trust  between  the  mili¬ 
tary  project  organization  and  the  contractor,  with 
very  close  cooperation  and  liaison  on  a  day-to-day 
basis . 

13.  Access  by  outsiders  to  the  project  and  its 
personnel  must  be  strictly  controlled  by  appro¬ 
priate  security  measures. 
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14.  Because  only  a  few  people  will  be  used  in 
engineering  and  most  other  areas,  ways  must  be 
provided  to  reward  good  performance  by  pay  not 
based  on  the  number  of  personnel  supervised. 
(29:170-171) 

Comparison  between  points  1,  2,  3,  11,  12,  and  13  witn  the 
earlier  management  principles  applied  on  the  Air  Force 
Ballistic  Missile  Program  shows  a  marked  similarity. 
Therefore,  these  management  principles  may  not  be  program 
specific . 

The  SKunk  Works  concept  is  a  sophisticated  version  of 
the  original  crash  program  philosophy  and  it  became  a  means 
co  rapidly  procure  extremely  capable  weapon  systems  as  a 
mounting  tide  of  restrictive  legislation  began  to  stretch 
the  acquisition  time  for  conventional  programs.  These 
programs,  sometimes  referred  to  as  "black"  programs,  lack 
tne  vast  scope  of  previous  crash  programs,  such  as  the  Air 
Force  Ballistic  Missile  program,  but  provided  necessary 
capability  in  an  environment  sheltered  from  excessive 
oversight.  As  a  result,  "the  Lockheed  "Skunk  Works”  under 
Clarence  "Kelly”  Johnson  has  become  synonymous  with  rapid 
development  times  from  concept  to  flight  hardware"  (6:15). 

Era  of  Controversy 

The  McNamara  Era.  Wnen  Robert  McNamara  was  appointed 
Secretary  of  Defense  in  the  newly  elected  Kennedy  Admini¬ 
stration,  he  usnered  in  a  period  of  military  acquisition  in 
which  tne  least  cost  approach  and  high  efficiency  were  the 


central  objectives  (9:8).  Influenced  by  his  background  at 
tne  Ford  Motor  Company,  McNamara  believed  the  same  profit- 
minded  efficiency  common  in  tne  private  sector  could  be 
achieved  in  government  programs.  His  principle  means  of 
achieving  this  goal  was  the  use  of  the  "paper  study."  These 
on-paper  assessments  were  considered  an  efficient  substitute 
for  the  earlier  costly  prototype  development  processes. 

Paper  studies  provided  a  highly  centralized  means  of  eval¬ 
uating  extremely  detailed  design  proposals.  However,  paper 
studies  only  affected  the  "front  end"  of  the  procurement 
process;  to  limit  the  government's  overall  acquisition 
costs,  the  Total  Package  Procurement  Concept  (TPPC)  was 
invented . 

Total  Package  Procurement.  The  TPPC  was  devised  by 
Robert  H.  Charles,  Assistant  Secretary  of  the  Air  Force  for 
Installations  and  Logistics,  who  worked  for  the  McDonnell 
Aircraft  Corporation  for  19  years  prior  to  entering  govern¬ 
ment  service.  Total  Package  Procurement  provided,  "...early 
in  the  procurement  cycle,  a  competitive  purchase  of  an  unde¬ 
signed  system  for  virtually  the  entire  life  cycle  of  the 
system"  (44:47).  Under  this  concept,  the  contractor  was 
required  to  provide  guarantees  on  the  performance  of  its 
still  theoretical  design.  The  Armed  Services  Procurement 
Regulation  (ASPR)  1-3310. 1(b)  provided  this  definition  of 
the  concept: 

TPP  is  a  method  of  procuring  at  the  outset  of  the 

acquisition  phase  under  a  single  contract  contain- 


ing  price,  performance  and  schedule  commitments, 
the  maximum  practical  amount  of  design,  develop¬ 
ment,  production  and  support  needed  to  introduce 
and  sustain  a  system  or  component  in  the  inven¬ 
tory.  (43:14) 

Tnerefore,  the  objective  of  the  TPPC  was  to  transfer  the 
procurement  risk  to  the  contractor  since  a  competitively  bid 
fixed  price  contract  extended  over  both  development  and 
production  phases.  Many  side  benefits  were  identified,  but 
there  were  three  primary  advantages  cited:  1)  the 
elimination  of  "buy-in"  bidding;  2)  the  elimination  of 
"gold-plating"  by  forcing  early  definition  of  specific 
government  requirements;  and  3)  the  government  would  ootain 
binding  commitments  from  contractors  concerning  price  and 
performance  of  weapon  systems  under  development  (51:134). 
Total  Package  Procurement  entailed  a  commitment  by  the 
government  to  production  of  the  weapon  system  at  contract 
award;  and  while  concurrency  was  common  during  the  1960's, 
TPP  became  the  ultimate  expression  of  the  strategy  (13:47). 

Tne  C-5A  Program .  The  Total  Package  Procurement 
Concept  was  originally  envisioned  to  be  used  only  for  system 
designs  which  used  existing  techniques  and  components  rather 
than  pushing  the  state-of-the-art  (44:49).  However,  the 
concept  was  ultimately  applied  to  major  Air  Force  systems 
such  as  the  C-5A  and  the  SRAM.  While  the  concept  was  used 
effectively  on  some  acquisition  programs,  its  results  on  tne 
C-5A  program  were  so  disastrous,  the  entire  total  package 
procurement  concept  was  discredited.  An  early  indication  of 
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trouble  occurred  during  the  source  selection  for  the  C-5A. 

A  1966  Ordnance  magazine  article  referred  to  a  total  of  over 
35  tons  of  paperwork  submitted  by  five  contractors  for  the 
paper  study  competition  on  the  C-5A  (30:232).  "One  contrac¬ 
tor  filled  an  entire  aircraft  with  data  and  flew  it  to 
Dayton,  Ohio,  for  evaluation"  (12:3).  Common  sense  dictates 
tnat  it  is  unreasonable  to  expect  any  source  selection  board 
(which  consisted  of  over  400  people),  to  be  able  to  absorb 
even  a  fraction  of  that  total.  As  a  example  of  the  complex¬ 
ity  of  the  contract's  numerous  clauses,  a  thirteenth-order 
differential  equation  was  used  to  determine  the  "produc¬ 
tivity  index"  which  could  either  reward  or  penalize  the 
contractor  for  his  contract  performance  (30:234).  Reacting 
against  this  bureaucratic  process.  Ordnance  magazine  wrote 
the  following  critique  of  TPPC  in  1966: 

If  the  same  effort  and  dollars  were  expended  on 
producing  competitive  flying  models  for  compara¬ 
tive  flight  tests  we  would  oe  much  more  likely  to 
select  the  superior  product  and,  if  the  current 
trend  continues,  at  the  end  of  a  much  shorter  time 
span.  (30:236) 

However,  the  problems  were  just  beginning — besides  the 
mountain  of  paperwork  which  the  TPPC  required,  its  built-in 
concurrency  also  contributed  to  the  problems  experienced  on 
the  C-5A  program. 

C-5A  Schedule  Compression .  While  TPP  authorized 
production  from  the  beginning  of  the  contract,  the  develop¬ 
ment  schedule  of  the  C-5A,  then  known  as  the  CX-X,  was  orig¬ 
inally  intended  to  have  low  schedule  compression.  General 
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Scnriever,  who  coined  the  term  "concurrency"  wnile  Commander 
of  the  Air  Force  Ballistic  Missile  Program,  was  now  Command¬ 
er  of  the  new  Air  Force  Systems  Command;  he  sougnt  to  build 
a  new  transport  aircraft,  capable  of  transporting  100,000 
pounds  of  cargo  10,000  miles,  to  become  operational  in  the 
1971-72  time  period  (43:155). 

However,  the  MATS  Commander,  General  Kelley,  and 
others  convinced  Secretary  McNamara  that  a  1969 
IOC  date  was  absolutely  essential  if  this  aircraft 
was  to  have  any  advantage  over  the  alternative  of 
building  more  C-141s.  (43:156) 

As  a  result.  Secretary  McNamara  decided  in  May  1964  the 
C-5  must  be  made  operationally  available  by  the  end  of  1969 
(43:156).  This  politically  motivated  action  necessitated  a 
schedule  compression  of  21  months.  To  achieve  this  degree 
of  concurrency,  Gen  Schriever  reduced  the  aircraft's  range 
requirement  from  10,000  co  5,500  nautical  miles,  but  other 
performance  parameters  remained  fixed.  However,  the  advent 
of  unplanned  schedule  compression  in  the  program  was  suffi¬ 
cient  to  cause  the  design  effort  to  suffer: 

Wnen  the  contractor's  proposals  were  critiqued  on 
1  September  1965,  one  month  had  already  passed 
since  the  compressed  schedule's  contract  award 
date  of  1  August.  Consequently,  the  new  Lockheed 
design  was  hastily  prepared  and  ill-defined.  The 
compressed  schedule  during  the  definition  phase 
contriouted  to  design  difficulties,  and  in  turn, 
the  deficient  design  became  a  cause  of  schedule 
difficulties  during  the  development  and  production 
phase.  (43:157) 

In  later  testimony  before  Congress,  Lockheed  confirmed  that 
concurrency  was  an  integral  part  of  its  Total  Package 
Procurement  contract.  According  to  H.  Lee  Poore,  the 
Executive  Vice  President,  Operations,  Lockheed-Georgia  Co., 
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Concurrency — with  its  advantages  and  disadvan¬ 
tages — came  with  the  C-5  contract.  It  was  not  a 
management  prerogative.  It  did  not  result  from  a 
Lockheed  management  decision.  We  accepted  it,  and 
the  inherent  products  of  its  environment. 

(60:1304) 

Causes  of  the  C-5A  Overrun.  Ultimately,  Lockheed 
was  forced  to  the  brink  of  bankruptcy  as  it  absorbed  large 
cost  overruns,  since  it  had  little  recourse  against  the 
government  because  it  was  locked  into  total  package  procure¬ 
ment's  fixed  price  contract.  While  the  higher  inflation 
that  resulted  from  President  Johnson's  "guns  and  butter" 
policy  affected  tne  cost  overrun  on  the  C-5,  tne  originally 
unplanned  schedule  compression  of  21  months  hindered  Lock- 
need's  early  design  effort  and  also  contributed  to  the  over¬ 
run.  But  Lockheed's  management  also  played  a  part  in  the 
disaster.  As  David  Packard  pointed  out,  "when  a  system  ends 
up  costing  twice  as  much  as  the  original  contract  target,  as 
did  the  C-5A  for  example,  there  is  no  explanation  but  to 
admit  it  was  bad  management"  (38:198).  For  instance,  the 
contract  contained  a  penalty  of  512,000  per  day,  per  air¬ 
craft  for  late  delivery,  up  to  a  maximum  of  $11  million,  but 
Lockheed  expended  mucn  larger  amounts  of  money  attempting  to 
avoid  tnis  $11  million  penalty  (43:155).  While  all  of  these 
factors  contributed  to  Lockheed's  difficulties,  the  concur¬ 
rency  mandated  on  tne  C-5A  Total  Package  Procurement  was 
identified  as  tne  primary  cause  of  problems  on  the  contract. 

Concurrency  Under  Fire.  As  the  McNamara  era  came  to  a 
close,  there  was  a  common  sentiment  among  top  level  offi- 
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cials  tnat  concurrency  was  the  "smoking  gun"  in  practically 
all  of  the  acquisition  programs  of  the  1960s  that  nad  run 
into  difficulties.  Following  Gen  Schriever's  success  on  tne 
Air  Force  Ballistic  Missile  Program  and  his  advocacy  of  the 
management  strategy  of  "concurrency,"  three  acquisition 
programs  were  selected  for  treatment  similar  to  the  earlier 
Ballistic  Missile  Program  (42:125).  The  8-70,  Skybolt,  and 
DynaSoar  programs  emulated  the  overlap  of  the  earlier  Atlas 
missile  program,  but  they  lacked  the  program  office  autonomy 
and  political  backing  of  their  predecessor,  and  all  three 
programs  failed  to  acnieve  any  degree  of  success.  Both  the 
B-70  and  Skybolt  programs  were  canceled  outright  due  to 
problems  of  cost  effectiveness,  and  th£  DynaSoar  program  was 
reduced  to  a  research  status  during  the  McNamara  years 
(42:125).  In  addition,  the  MBT-70,  Cheyenne,  and  Condor 
programs,  all  concurrent  and  all  ultimately  canceled,  also 
provoked  increasing  numbers  of  critics,  both  within  and  out¬ 
side  the  DoD,  to  question  initiating  production  activities 
prior  to  completion  of  the  development  effort.  Other  con¬ 
current  programs,  even  those  that  did  not  "push"  the  state- 
of-the-art,  such  as  the  Army's  Gamma  Goat  truck,  experienced 
both  cost  and  performance  problems.  These  problems  were 
encountered  despite  a  DoD-wide  policy  favoring  a  sequential 
acquisition  approacn: 

Each  of  the  three  services  has  longstanding  poli¬ 
cies  that  require  the  completion  of  engineering 
testing  before  production  begins,  but  tnese  poli¬ 
cies  have  been  frequently  waived.  For  instance, 


the  Array  has  such  a  policy,  but  it  also  provides 
for  waiving  the  policy  to  begin  limited  production 
because  certain  exceptional  circumstances  exist 
(i.e.,  urgency  of  need  and  low  risk).  Most,  if 
not  all,  of  the  major  weapon  systems  have  been 
procured  under  this  waiver.  Similarly,  the  MARK 
48  torpedo,  the  F— 111  aircraft,  and  a  number  of 
other  weapon  systems  in  the  Navy  and  Air  Force 
have  entered  production  under  waivers  to  the 
overall  policy.  (11:35) 

Fly-Before-Buy.  When  the  Nixon  Administration  entered 
office,  David  Packard  was  appointed  Deputy  Secretary  of 
Defense.  Following  his  30  May  1969  memorandum  outlining  a 
new  milestone  strategy.  Secretary  Packard  issued  his  31  July 
1969  memorandum  entitled  "Improvement  In  Weapon  System 
Acquisition"  (18:2).  Through  these  two  memoranda,  Dep  Sec 
Packard  initiated  military  acquisition  policy  changes  which 
form  the  modern  DOD  procurement  environment.  Chief  among 
these  changes,  and  central  to  this  discussion,  was  the 
disavowal  of  the  concurrency  strategy  and  resurrection  of 
the  prototyping  strategy  of  the  1950’s,  incorporating 
decision  milestones,  which  he  called  "fly-before-buy."  Dep 
Sec  Packard's  action  reflected  increased  DOD  dissatisfaction 
with  the  results  of  concurrency.  These  results,  which  Dep 
Sec  Packard  described  as  "the  disastrous  results  of  concur¬ 
rency,"  and  the  publicity  surrounding  the  new  fly-before- 
you-buy  policy,  spurred  both  the  Administration  and  Congress 
toward  an  inflexible  posture  favoring  sequential  weapon  sys¬ 
tem  acquisition.  In  Secretary  Packard's  words:  "As  I 
reviewed  program  after  program  beginning  in  tne  Spring  of 
1969,  almost  all  were  in  trouble  from  a  common  fault — 
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production  had  been  started  before  engineering  development 


was  finished"  (36:4).  His  solution  was  a  new  emphasis  on 
sequential  acquisition: 

The  program  schedule  (structure)  is  another  very 
key  consideration.  It  must  make  sense.  It  must 
allow  time  for  accomplishing  important  task  objec¬ 
tives  without  unnecessary  overlapping  or  concur¬ 
rency.  The  ideal  schedule  is  sequential  with 
enough  slack  time  for  resolution  of  those  problems 
which  inevitably  arise  in  any  develoomenc  program. 
(39:30) 


This  solution  was  implemented  through  three  policy  state¬ 
ments:  first,  the  elimination  of  total  package  procurement 

on  major  programs  (a  movement  back  to  its  originally 
envisioned  purpose);  second,  cost-incentive  type  contracts 
would  be  encouraged  for  development  contracts;  and  third, 
fixed  price  production  contracts  would  be  negotiated  only 
after  system  design  was  proven  (36:200). 

Congressional  Support  For  Fly-Before-Buy .  Congress 
found  the  policy  of  f ly-oef ore-you-buy  very  appealing,  but 
in  its  appropriation  hearings,  was  often  dismayed  to  find 
concurrency  remaining  in  the  procurement  strategies  for 
major  weapon  systems.  For  instance,  in  a  hearing  on  22 
April  1970,  congressmen  heard  testimony  from  Navy  Secretary 
Chafee  tnat  if  Congress  did  not  support  the  use  of  concur¬ 
rency  on  the  F-14  program,  an  additional  penalty  of  $896 
million  would  be  incurred  for  a  12  month  production  breax 
and  program  delay.  The  following  testimony  illustrates  the 
controversy  surrounding  the  fly-bet ore-you-buy  policy: 
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Mr.  Mahon.  Is  the  Navy  dedicated  to  the  view  that 
fly-before-buy  is  not  a  good  process  and  that  you 
should  have  concurrency  in  the  procurement  of  air¬ 
craft? 

Secretary  Chafee.  No  sir.  What  we  are  trying  to 
do,  as  much  as  we  can,  is  have  a  fly-before-buy 
program. 

Mr.  Mahon.  This  plane  won't  fly  until  January, 
and  yet  you  are  buying  operational  aircraft? 

Secretary  Chafee.  Against  that  we  have  got  to 
balance  the  production  line  problems  of — 

Mr.  Mahon.  These  are  real  problems.  I  am  not 
sympathetic.  Aren't  you  saying  it  is  not  feasible 
to  nave  a  program  of  fly-before-buy? 

Secretary  Chafee.  We  believe  it  is  not  feasible 
with  a  complex  airplane.  I  don't  think  a  straight 
fly-before-buy — turn  off  the  production  line  until 
the  aircraft  gets  up  in  the  air  and  everybody 
tries  it  out  and  then  start  up  a  production  line 
again — I  don't  think  that  is  practical.  (55:1114) 

The  fly-before-buy  policy  was  not  yet  one  year  old  and 

although  all  the  services  acknowledged  the  theoretical 

advantages  of  following  such  a  policy,  in  practice  many 

individual  acquisition  programs  retained  some  degree  of 

concurrency.  However,  soon  after  this  testimony,  the 

Fitznugh  Commission  (also  known  as  the  Blue  Ribbon  Defense 

Panel)  issued  its  report  on  1  July  1970. 

The  Fitzhugh  Commission  had  been  tasked,  among  other 

responsibilities,  to  study  defense  procurement  policies  and 

practices.  Its  final  report  recommended  "a  general  rule 

against  concurrent  development  and  product  efforts,  with  the 

production  decision  deferred  until  successful  demonstration 

of  developmental  prototypes"  (15:8).  Armed  with  the  conclu- 


sions  of  this  report  and  inclined  to  err  on  the  side  of  cau¬ 
tion,  many  Congressmen  favored  a  sequential  strategy — but 
even  the  progenitor  of  the  fly-before-buy  policy  seemed  to 
be  experiencing  second  thoughts. 

Fly-Bef ore- Buy  Policy  Modification.  Dep  Sec  David 
Packard  seemed  to  temporarily  modify  his  sequential  policy 
stance  when  he  appeared  before  the  Committee  on  Appropria¬ 
tions  on  18  March  1971.  His  statement  on  fly-before-buy 
read:  "engineering  development  must  be  complete  before 

substantial  commitment  to  production  is  made"  (56:14).  This 
new  wording  of  "substantial  commitment"  opened  the  door  to 
low-rate  funding  of  production.  Previous  to  this,  the  only 
potential  overlap  Packard  acknowledged  was  "some  limited 
expenditure  on  production  may  have  to  overlap  development" 
(39:31).  But  in  the  previous  case,  the  production  engineer¬ 
ing  and  tooling  was  limited  to  a  demonstration  that  develop¬ 
ment  engineering  was  complete  (39:31).  In  further  testimony 
before  the  committee,  Packard  went  on  to  explain  that  "it  is 
clear  that  discussions  of  the  policy  of  f ly-bef ore-you-buy 
often  have  over-emphasized  a  literal  interpretation  and 
under-emphasized  its  real  meaning"  (56:18).  He  also  specif¬ 
ically  endorsed  a  low-rate  production  strategy  using  the 
F-15  program  as  an  example: 

The  F- 1 5  program  is  also  structured  with  milestone 
checkpoints.  Some  funds  will  be  required  for  pro¬ 
duction  tooling,  and  for  some  long  lead-time  items 
before  development  and  testing  is  complete;  but 
production  will  be  held  at  a  very  low  level  until 
we  have  assurance  that  development  is  complete-- 


56 


and  only  then  will  the  production  increase  be 
authorized.  (56:13) 

In  effect,  Mr.  Packard  was  endorsing  a  policy  of  separate 
low-rate  and  high-rate  production  decisions  where  low-rate 
production  is  allowed  to  overlap  development  activity. 
However,  the  battle-lines  had  been  drawn. 

Disagreement  Within  The  DoD.  Advocates  of  concurrent 
and  sequential  procurement  existed  within  both  the  Depart¬ 
ment  of  Defense  and  Congress,  and  on  any  given  day  in 
hearings  before  Congress  on  DOD  acquisition,  arguments  both 
for  and  against  the  use  of  concurrency  were  presented.  Just 
two  months  after  Mr.  Packard's  testimony.  Assistant  Secre¬ 
tary  DeRosa,  representing  the  R&D  community,  presented  a 
forceful  argument  for  encouraging  a  high  degree  of  concur¬ 
rency  (61:3261).  But  18  days  later,  former  Assistant  Secre¬ 
tary  of  Defense,  Comptroller,  Robert  N.  Anthony,  recommended 
the  total  elimination  of  concurrency  unless  the  need  was 
urgent  (59:441).  But  the  very  next  witness,  J  Ronald  Fox, 
Assis-tant  Secretary  of  the  Army,  Installations  and  Logis¬ 
tics,  testified  before  the  committee  favoring  the  use  of 
concurrency,  citing  an  overwhelming  need  and  the  necessity 
of  promoting  the  efficient  use  of  manpower  in  the  contrac¬ 
tor's  plant  as  two  primary  reasons  for  concurrent  scheduling 
(59:473-474).  There  are  other  examples  of  Congressional 
testimony  in  which  concurrent  or  sequential  acquisition  was 
advocated  by  different  members  of  the  Department  of  Defense, 
out  the  point  is  made  that  there  was  no  concurrence  within 

the  DOD  about  the  use  of  concurrency. 
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Ac  the  s i.ne  time,  reports  continued  to  be  published 

favoring  sequential  acquisition  strategies.  The  Rand  report 

"System  Acquisition  Strategies,"  puolished  in  June  1971, 

made  this  recommendation: 

...the  evidence  suggests  tnat  tne  normal  mode  of 
acquiring  weapon  systems  during  the  1970s  prooably 
should  be  based  on  an  incremental  acquisition 
strategy,  witn  tne  exceptions  being  determined  by 
such  special  considerations  as  mignt  occur. 

( 59  :  vi ) 

Despite  the  various  studies  which  recommended  a  sequential 
strategy,  overlap  of  low-rate  production  and  development 
remained  common  in  military  acquisition.  In  nearings  on  29 
September  1971,  Senator  Proxmire  became  exasperated  by  the 
unwillingness  of  Department  of  Defense  Program  Managers  to 
abandon  concurrency: 

Senator  Proxmire.  That  is  the  recommendation  of 
the  Fitzhugh  report,  all  of  the  reports,  that  you 
should  fly  before  you  buy  and  get  out  the  bugs  in 
research  oefore  you  go  into  production;  but  the 
Defense  Department  is  not  doing  it.  They  are  noz 
doing  it.  They  are  not  doing  it  with  tne  ABM  or 
any  number  of  other  major  systems.  They  should  be 
doing  it.... There  is  no  evidence  they  have  gone 
this  way.  They  nave  converted  this  into  a  cost 
plus  whicn  is  not  much  of  an  improvement,  but 
there  is  not  evidence  that  they  have  insisted  that 
they  are  going  to  complete  the  research  and  the 
prototype  development,  and  then  determine  wnat 
they  have  before  they  go  into  production.  They 
snould,  but  they  are  not  doing  it.  (60:1383) 

Senator  Proxire  was  also  frustrated  in  his  attempt  to  pass 

an  amendment  requiring  notification  of  Congress  anytime 

concurrency  was  employed  on  a  military  acquisition  program. 


According  to  Senator  Proxmire' s  comments,  tne  Departaient  of 


Defense  successfully  lobbied  the  rest  of  the  Senate  to  vote 


down  this  amendment  (60:1389) 


By  the  time  David  Packard  returned  to  the  private 

sector  in  December  of  1971,  Mr.  Packard  seemed  to  share 

Senator  Proxmire's  frustration  over  the  unwillingness  of  the 

Department  of  Defense  to  eliminate  concurrency.  In  a 

Defense  Management  Journal  article  dated  July  of  1972,  he 

made  his  most  strident  comments  about  this  attitude: 

A  few  months  ago  at  a  meeting  of  military  project 
managers,  someone  objected  to  extensive  testing 
because  it  would  delay  the  program.  He  complained 
that  testing  showed  up  things  that  needed  to  be 
fixed  and  it  took  time  to  fix  them,  and  this  would 
delay  the  initial  operating  capability.  Unless  we 
get  rid  of  that  kind  of  thinking  there  will  be  no 
hope.  (37:6) 

He  also  blasted  the  concurrency  strategy: 

There  are  some  practices  in  this  business  which 
are  real  waste  rather  than  conspicuous  waste. 

There  has  been  real  waste  of  both  time  and  money 
in  almost  every  program  in  which  production  was 
started  before  development  and  testing  was  com¬ 
plete.  That  includes  almost  every  program.  (37:4) 

Remarkably,  tne  unwillingness  on  the  part  of  some  DoD 
personnel  to  adopt  a  true  fly-before-buy  philosophy  was 
evident  even  in  a  whole  July  1972  Defense  Management  Journal 
issue  dedicated  to  the  idea  of  prototyping.  In  the  article 
following  Mr.  Packard's,  Maj  Gen  George  Sammet  Jr.,  the  Army 
Deputy  Chief  of  Research  &  Development,  provided  this  unique 
interpretation  of  Packard's  earlier  statements  on  proto¬ 
typing  : 

When  the  phrase,  fly  before  buy,  was  first  heard 
in  the  Packard  context,  many  jumped  to  the  con¬ 
clusion  that  it  meant  an  inviolate  system  of 
sequential  development,  test,  and  production. 
Concurrency  was  to  be  eliminated;  programs  would, 
as  a  result,  be  stretched  out;  considerably  more 


testing  would  be  required;  and,  more  than  likely, 
there  would  be  added  program  costs.  To  a  degree, 
he  intended  some  of  these  but,  again,  what  I 
believe  he  really  had  in  mind  was  a  mechanism  or 
technique  to  eliminate  or  reduce  uncertainty. 

(50:7) 

Maj  Gen  Sammet  went  on  to  make  a  proposal  totally  contrary 

to  Packard's  comments  of  only  a  few  pages  earlier: 

We  believe  that,  in  line  with  former  Secretary 
Packard's  objectives  of  improving  defense  systems 
acquisition  and  without  violating  any  of  his 
goals,  we  can  shorten  the  process  to  about  six 
years  from  initiation  of  engineering  development 
to  first-unit-equipped.  This  does  envision  les¬ 
sening  of  the  heel-to-toe  sequence  and  an  accep¬ 
tance  of  some  controlled  concurrency.  (50:10) 

In  later  pages,  John  Baumgartner,  of  the  Defense  Systems 

Management  School,  also  questioned  the  sequential  strategy 

and  made  this  observation: 

Logical,  orderly  project  scheduling  may  reduce  the 
costs  of  concurrency;  but  a  tight  schedule,  with 
its  inherently  greater  acquisition  costs,  may  well 
give  a  longer  product  life  and,  thus,  greater 
economic  value.  (7:56) 

Although  the  controversy  among  managers  continued,  the 
issuance  of  DoD  directive  5000.1,  dated  13  July  1971, 
provided  tne  means  to  reduce  the  built-in  concurrency  of 
some  programs.  In  addition  to  formal  DSARC  milestones,  this 
instruction  cautioned  against  the  use  of  "unnecessary 
concurrency . H 

Despite  the  misgivings  of  some  concurrency  advocates, 
DoD  acquisition  did  become  more  sequential  during  the  1970s. 
The  fly-offs  for  the  A-X  and  Light  Weight  Fighter  programs 
were  the  ultimate  expression  of  Packard's  prototyping  strat- 


egy.  Also,  the  P-15  and  the  AWACS  programs  used  proto¬ 
typing;  wnile  no  fly-off  for  the  aircraft  fuselage  occurred, 
subsystems  within  the  aircraft  were  involved  in  a  "fly-off" 
evaluation  (21:16).  Other  smaller  systems,  such  as  25mm  and 
30mm  gun  systems  and  subsystems  for  the  Subsonic  Cruise 
Armed  Decoy  (SCAD)  missile  were  prototyped  (21:16). 

However,  the  pendulum  was  already  beginning  to  swing  back  in 
the  other  direction  nearly  ten  years  after  David  Packard 
proposed  his  sequential  strategy. 

Defense  Science  Board 1 s  Study .  In  1977,  Dr.  William  J. 
Perry,  the  Under  Secretary  of  Defense  for  Research  and 
Engineering,  commissioned  a  Defense  Science  Board  Task  Force 
to  study  the  increasing  length  of  the  acquisition  cycle  and 
to  make  recommendations  on  how  to  improve  the  military 
procurement  process  (23:14).  On  15  March  1978,  the  Defense 
Science  Board  published  its  "Report  of  the  Acquisition  Cycle 
Task  Force."  One  of  the  primary  findings  of  this  report  was 
the  following: 

That  the  acquisition  process  has  gone  to  unreason¬ 
able  limits  in  discouraging  concurrency  and  in 
overempnasizing  advanced  development  prototypes 
even  when  these  add  more  to  program  cost  and 
acquisition  time  tnan  they  benefit  it  by  reducing 
risk.  ( 1 3 : v ) 

However,  this  statement  was  not  an  unconditional  endorsement 
for  the  use  of  a  high  degree  of  concurrency  in  every  acquis¬ 
ition  program.  Although  tne  Task  Force  recognized  concur¬ 
rency  is  a  fact  of  life  in  military  procurement,  it  tempered 
its  advocacy  of  concurrency  with  tne  following  statement: 


"the  amount  or  degree  of  such  concurrency  should  be  based  on 

the  extent  of  technical  risk  and/or  national  urgency  in  each 

particular  acquisition  program"  (13:47).  Also,  the  Task 

Force  members  took  issue  with  Packard's  conclusion  about  the 

"disastrous  effects  of  concurrency."  Tne  study  analyzed  63 

acquisition  programs  and  concluded: 

no  clear  correlation  between  concurrency  and  poor 
quality  of  the  end  product  could  be  discerned  from 
the  data  examined  by  the  Task  Force.  On  the  con¬ 
trary,  the  argument  can  be  made  that  some  of  the 
most  highly  concurrent  programs  were  also  the  most 
successful  in  terras  of  meeting  schedule  and  cost 
goals  as  well  as  established  system  performance 
objectives  (e.g.,  F-5E,  Polaris,  Minuteman,  Boeing 
727).  (13:50) 

To  reverse  the  effects  of  Packard's  fly-before-buy  policy, 
the  Task  Force  recommended  five  changes  in  DoD  Directive 
5000.1  which  relate  directly  to  their  advocacy  of  concur¬ 
rency: 

1.  Permit  concurrency  in  the  acquisition  process. 

2.  Explicitly  state  that  approval  for  FSD  in¬ 
cludes  the  intent  to  deploy. 

3.  Encourage  the  combining  of  decision  milestones 
where  possible. 

4.  Discourage  "system"  prototypes  unless  they  are 
producible . 

5.  Establish  DSARC  III  as  the  approval  point  for 
rate  production.  (13:33) 

Of  special  significance  to  Air  Force  acquisition  in  the  mid- 
1980s,  Maj  Gen  Skantze  was  one  of  the  Task  Force  members — he 
is  currently  Commander  of  Air  Force  Systems  Command.  Unlike 
Packard's  sequential  acquisition  preference,  the  Task  Force 
did  not  reject  his  advocacy  of  prototyping. 


The  Acquisition  Cycle  Task  Force  endorsed  a  flexible 
policy  toward  the  use  of  prototyping.  For  instance,  the 
report  states:  "when  a  new  system  presses  the  technological 
state-of-the-art  or  when  there  are  several  attractive  solu¬ 
tions,  a  prototype  can  often  be  employed  to  great  advantage" 
(13:53).  But  it  also  concluded  that  excesses  had  existed  in 
tne  prototyping  policy  of  the  1970s: 

there  are  examples  in  recent  programs  (e.g.,  A- 
10/A-9,  F-16/F-17)  where  little  benefit  can  be 
found  in  the  use  of  prototypes  in  terms  of  shor¬ 
tening  the  development  cycle,  reducing  overruns, 
reducing  overall  cost,  or  minimizing  risk.  (13:53) 

The  Task  Force  only  rejected  the  use  of  system  prototyping 

for  low  to  moderate  technical  risk  programs — it  endorsed 

competitive  prototyping  at  less  than  the  system  level 

(13:54) . 

To  summarize,  the  Task  Force  concluded  that  proto¬ 
typing  can  be  a  sound  and  useful  practice  in  major 
systems  acquisitions  provided  that  the  candidates 
for  the  use  of  prototypes  are  carefully  selected, 
that  only  those  things  are  prototyped  which  really 
need  verification,  and  that  prototypes  are  not 
considered  to  be  some  form  of  "free  lunch"  for  the 
procuring  agency.  (13:54) 

Concurrency  Resurrected .  As  a  result  of  the  Task 
Forces'  recommendations,  DoD  Directive  5000.1  was  revised  to 
remove  its  bias  against  the  use  of  concurrency.  In 
addition,  many  major  acquisition  programs  were  planned  to 
incorporate  a  high  degree  of  concurrency — including  the 
following : 

1 .  M-1  Tank 

2.  DIVAD  Gun 

3.  Multiple  Launch  Rocket  System 


4.  Air  Launched  Cruise  Missile 

5.  TR-1  Aircraft 

6.  C-X  Aircraft 

7.  AMRAAM  Missile 

8.  HARM  Missile 

9.  Ground  Launched  Cruise  Missile 

10.  Bradley  Fighting  Vehicle 

11.  F/A-18 

12.  SURTASS  Sensor  (57:26,374) 

13.  B- 1 B  Aircraft 

The  new  enthusiasm  for  the  use  of  concurrency  was  also 
evident  in  testimony  oefore  Congress,  during  tne  1980-81 
time  period,  it  was  no  longer  a  question  of  whether  or  not 
to  use  concurrency  in  system  acquisition,  only  a  question  o 
wnat  degree  should  be  employed  on  each  program.  According 
to  Dr.  William  Perry,  the  DoD  Acquisition  Executive,  this 
action  was  taken  with  the  encouragement  of  Congress  (57:26) 
But,  in  his  statement  on  "Acquisition  Policy  &  Procedures," 
he  explained  that  major  schedule  compression  was  to  be  ap¬ 
plied  on  a  flexible  basis  depending  on  the  specific  program 
"we  may  elect  to  accelerate  early  production  and  incur  addi 
tional  risk  of  concurrency  (in  development  and  production) 
in  order  to  meet  a  critical  operational  capability  date" 
(53:670).  Yet,  even  in  those  cases,  he  demonstrated  a 
willingness  to  maintain  low-rate  production  until  major 
development  problems  were  resolved: 

Great  care  must  be  taken  in  the  selection  of 
programs  for  accelerated  procedures.  Technical 
risk  must  be  low,  and  special  management  auditing 
must  be  used  to  get  early  warnings  of  trouble.  We 
were  using  accelerated  procedures  on  the  HARM  mis¬ 
sile,  for  example,  and  when  developmental  problems 
arose,  we  canceled  plans  to  begin  concurrent  pro¬ 
duction.  We  also  experienced  test  problems  on  tne 
Xrt-1  tank  and  kept  concurrent  production  at  a  low 


rate  until  we  were  able  to  incorporate  fixes  and 
retest  tne  modified  tank.  (57:26) 

Or.  Perry's  testimony  at  that  time  didn't  reflect  how 

difficult  it  was  to  retain  the  M-1  in  low  rate  production. 

In  the  June  1986  issue  of  Military  Logistics  Forum,  Dr. 

Perry  explained  some  of  the  behind-the-scenes  conflict  that 

occurred  at  that  time: 

We  had  a  real  knock-down,  drag-out  fight  on  the 
M-1,  for  example.  The  Army  wanted  to  put  it  into 
nigh-rate  production,  and  the  testing  at  the  time 
obviously  didn’t  support  that.  The  Army  reasoned 
that  the  program  was  structured  that  way,  and  it 
would  be  a  great  catastrophe  were  it  to  stop  at 
this  stage.  (31:55) 

So,  while  the  use  of  concurrency  may  be  justified,  if  the 

policy  is  inflexibly  institutionalized,  serious  procurement 

problems  will  likely  result.  Returning  to  Dr.  Perry's 

testimony  before  the  committee,  he  summarized  his  position 

on  concurrency  with  this  cautious  statement: 

We  have  no  doubt  that  under  placid  world  condi¬ 
tions  with  no  looming  hostile  military  threat  that 
a  step-by-step  approach  to  systems  development  and 
procurement  may  be  the  most  productive  course.  It 
gives  us  the  opportunity  to  change  our  minds  at 
several  points  along  the  way. 

Even  in  perilous  times,  technology-intensive  sys¬ 
tems  with  a  high  risk  factor  may  still  require  a 
heel-to-toe  approach  to  avoid  potentially  disas¬ 
trous  technical  pitfalls.  However,  where  the  need 
is  great,  or  the  technology  is  less  demanding, 
our  commitment  to  the  program  should  come  early  in 
the  program  and  in  these  cases  concurrency  should 
be  used.  (57:618) 

Mr.  Church,  the  Deputy  Under  Secretary  of  Defense  for 
Research  and  Engineering,  also  reflected  the  change  of 
attitude  toward  concurrency  when  he  testified  on  5  June 


1980.  He  summarized  the  new  philosophy  in  a  discussion  with 
Representative  Bill  Chappell  of  Florida. 

Mr.  Church.  I  don't  know  of  a  single  weapon 
system  that  has  been  developed  in  the  last  100 
years  that  nasn't  had  some  degree  of  concurrency. 

Mr.  Chappell.  Is  some  degree  of  concurrency 
essential? 

Mr.  Church.  I  have  to  conclude  that  some  degree 
of  concurrency  is  essential.  The  only  question 
then  becomes  one  of  management  deciding  to  wnat 
degree.  (57:364) 

So,  within  four  years  of  the  release  of  the  Defense  Science 
Board  1977  Summer  Study,  concurrency  was  again  strongly 
advocated  for  defense  acquisition.  But  the  DIVAD  gun  system 
provided  ammunition  to  critics  of  concurrency  that  began  to 
swing  the  pendulum*  back  toward  a  more  sequential  process. 

DIVAD  Gun  System.  The  division  air  defense  gun  was  "a 
highly  accelerated,  concurrent  program"  (57:337).  Dr.  Perry 
even  claimed  on  27  February  1980,  that  it  was  one  of  the 
most  concurrent  programs  the  DoD  was  conducting.  He  felt 
the  decision  to  compress  the  schedule  was  justified  because 
tne  concept  used  a  proven  tank  chassis,  the  proven  Bofors 
gun,  and  the  radar  system  from  tne  F-16.  In  addition, 
management  principles  patterned  after  "Kelly"  Johnson's 
Lockheed  Skunk  Works  programs  were  employed.  To  reduce  the 
acquisition  risk  even  further,  competition  between  two  con¬ 
tractors  was  also  used.  From  all  appearances,  the  DIVAD  gun 
should  nave  been  the  crowning  achievement  of  the  concurrency 
strategy.  Of  course,  the  actual  result  was  program  cancel- 


lation  after  an  initial  production  run  of  132  vehicles. 

Critics  of  concurrency  rose  to  the  occasion  to  claim  that 

the  DIVAD  program  failed  because  concurrency  failed  (16:1). 

However,  those  opponents  of  concurrency  who  use  the  DIVAD 

gun  as  their  1980's  version  of  the  C-5A  should  consider 

whether  any  amount  of  time  would  have  been  sufficient  to 

perfect  the  DIVAD  program  as  it  was  envisioned.  It  appears 

that  the  narrow  focus  on  a  specific  gun  and  radar  system 

paralleled  by  an  increasingly  challenging  Soviet  helicopter 

threat  were  the  central  problem  faced  by  the  program.  As 

Jacques  Gansler  concluded: 

the  only  lesson  that  snould  be  drawn  from  Secre¬ 
tary  Weinberger's  cancellation  of  the  Division  Air 
Defense  anti-aircraft  gun  is  that  there  is  little 
value  in  rapidly  developing  and  producing  the 
wrong  system.  (19:47) 

Air  Force  Concurrent  Programs .  The  Air  Force's  AMRAAM 
program  has  suffered  from  cost  problems  which  threaten 
cancellation  of  tne  program  and  its  problems  have  been 
attributed  by  some  critics  to  the  schedule  compression  built 
into  the  program.  However,  many  times  in  military  acquis¬ 
ition,  a  concurrent  program  may  experience  controversy  in 
development  and  ultimately  prove  very  successful.  The  F-14 
fighter  aircraft,  tne  M-1  tank,  and  the  Minuteman  missile 
are  examples  of  this  phenomena.  Therefore,  no  conclusions 
can  yet  be  drawn  about  the  AMRAAM  program's  effect  on  the 
use  of  concurrency.  In  addition,  the  highly  concurrent  and 
vary  successful  3-1B  program  (admittedly  a  re-start  rather 


than  a  ground  up  development)  has  balanced  the  effect  of  the 
AMRAAM  missile  on  current  Air  Force  attitudes  toward  concur¬ 
rency.  But  the  Packard  Commission  has  ushered  in  changes 
that  will  affect  DoD  acquisition  regardless  of  the  ultimata 
fate  of  the  AMRAAM  program. 

The  Packard  Commission .  When  President  Reagan  appoint¬ 
ed  the  Blue  Ribbon  Commission  on  Defense  Management,  advo¬ 
cates  of  concurrency  had  cause  to  hold  their  breath  because 
David  Packard  stepped  back  into  the  spotlight  to  head  the 
task  force.  However,  for  the  specific  study  of  military 
acquisition,  Mr.  Packard  delegated  the  investigation  to  none 
otner  than  Dr.  William  Perry.  As  is  evident  from  prior 
quotations  from  both  gentlemen,  their  respective  views 
toward  the  use  of  concurrency  seem  to  mix  like  oil  and 
water.  However,  it  is  apparent  that  a  common  ground  was 
strucx  and  tne  recommendations  the  Commission  made  not  only 
do  not  impede  the  use  of  concurrency,  but  will  likely 
improve  its  future  effectiveness. 

A  central  finding  of  the  final  report  (also  found  in 
tne  Defense  Science  Board's  1977  Summer  Study)  is  that  "with 
notable  exceptions,  weapon  systems  take  too  long  and  cost 
too  much  to  produce"  (14:xxii).  This  statement  is  clarified 
later  in  tne  report  when  the  Commission  explains  that  the 
acquisition  cycle  is  averaging  "ten  to  fifteen  years  for  our 
major  weapon  systems"  (14:47).  The  Packard  Commission  also 
concludes  that  a  long  acquisition  cycle  leads  to  "unneces- 
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sarily  high  costs  of  development"  and  "leads  to  obsolete 
technology  in  our  fielded  equipment"  (14:47).  However,  the 
report  does  recognize  some  "notable  exceptions"  to  this 
general  rule: 

...the  Acquisition  Task  Force  examined  several  DoD 
programs  that  were  developed  under  special  stream¬ 
lined  procedures — the  Polaris  missile,  the  Minute- 
man  missile,  the  air-launched  cruise  missile 
(ALCM) ,  and  several  highly  classified  projects. 

We  found  that,  in  these  programs,  DoD  achieved  the 
accelerated  schedules  of  the  successful  commercial 
programs .  (14:49) 

In  other  words,  by  using  special  streamlined  procurement 
procedures,  all  of  these  concurrent  programs  were  highly 
successful . 

The  second  conclusion  related  to  the  use  of  concurrency 

is  the  Commission's  endorsement  of  risk  reduction  through 

the  use  of  prototyping.  Unfortunately,  the  report  also 

mentions  a  variant  of  the  phrase  "fly-before-buy".  Because 

of  previ-ous  experience  from  the  early  1970s,  this  phrase 

will  likely  confuse  the  Commissions ' s  actual  risk  reduction 

intent,  which  appears  to  oe  fully  compatible  with  the  use  of 

concur-rency .  As  an  example,  the  following  quotation  is 

practi-cally  a  restatement  of  the  Defense  Science  Board's 

1977  conclusion  on  prototyping: 

A  nigh  priority  should  be  given  to  building  and 
testing  prototype  systems  and  suosystems  before 
proceeding  with  full-scale  development.  This 
early  phase  of  R&D  should  employ  informal  compet¬ 
ition  and  use  streamlined  procurement  processes. 

(14: xxv ) 
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This  risk  reduction  phase  philosophy  is  already  being  used 
on  some  concurrent  Air  Force  programs  like  the  SRAM  II  and 
does  not  appear  to  hinder  the  use  of  concurrency. 

Finally,  the  report  stresses  a  separate  low-rate,  high- 
rate  production  decision.  It  appears  that  considerable 
latitude  is  accorded  the  Program  Manager  as  to  the  decision 
of  when  to  initiate  production,  but  high-rate  production  is 
not  to  commence  until  the  low-rate  production  units  are 
"subjected  to  intensive  operational  testing"  (14:xxvi). 

Effects  of  the  Packard  Commission .  While  it  will 
likely  taka  at  least  five  years  for  tne  implementation  of 
tne  Packard  Commissions'  recommendations  to  work  their  way 
into  the  system  and  affect,  the  products  of  Air  Force  acqui¬ 
sition,  preliminary  changes  related  to  Packard's  emphasis  on 
prototyping  nave  already  been  initiated.  According  to 
Deputy  Secretary  of  Defense  Taft: 

Beginning  with  the  Advanced  Tactical  Fighter  [ATFJ 
program,  which  has  just  shifted  to  that  format, 
you  will  be  seeing  more  prototyping,  [including 
LHX ,  the  Army's  new  'true  hover'  helicopter,]  and 
a  variety  of  other  programs.  (51:26) 

This  prototyping  is  likely  to  be  encouraged  by  Congress, 
since  Congressmen  such  as  Representative  Denny  Smith,  a  co- 
chairman  of  the  Military  Reform  Caucus,  have  become  increas¬ 
ingly  disenchanted  with  concurrent  programs.  He  recently 
made  this  olunt  statement  in  the  June  1986  issue  of  Military 
Logistics  Forum:  "concurrency  isn't  needed  unless  we're  in 
a  real  wartime  situation"  (35:46). 
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Therefore,  given  past  experience,  it  appears  that 
simple  schedule  compression  or  concurrency  performed  within 
the  mainstream  acquisition  environment  will  likely  continue, 
but  like  the  1970s,  it  may  not  be  an  "approved"  topic  for 
discussion.  However,  there  is  also  a  parallel  movement 
within  the  Department  of  Defense  which  seeks  to  combine  the 
use  of  concurrency  with  the  "special"  or  "exempt"  program 
status  wnich  has  produced  notable  acquisition  successes  in 
the  past. 

Streamlined  Programs .  The  term  describing  this 
approach  is  known  as  "streamlining"  or  streamlined  acqui¬ 
sition  procedures.  In  fact.  Air  Force  Regulation  800-29, 
"Application  of  Specialized  Management"  provides  the 
guidelines  for  the  management  of  these  special  programs.  In 
a  nutshell, 

"specialized  management”  is  a  system  designed  to 
cut  through  red  tape  and  enable  selected  people  to 
bypass  routine  management  requirements,  some 
staff,  and  get  on  with  the  task  at  hand.  (6:15) 

Tne  Defense  Science  Board's  recent  study  entitled  "Practical 

Functional  Performance  Requirements",  and  referenced  by  the 

Packard  Commission  report,  also  provides  support  for  this 

concept.  Of  even  greater  significance,  some  highly  regarded 

Congressmen  are  supporting  this  approach. 

In  an  interview  with  Aviation  Week  and  Space 
Technology,  Senator  Nunn  said  if  a  few  candidate 
programs  could  be  identified  for  specialized  man¬ 
agement,  he  would  give  them  "one  paragraph  treat¬ 
ment"  in  law.  That  paragraph  would  say,  basi¬ 
cally:  "We  want  this  done  with  an  effective  and 

efficient  procurement  method  with  the  maximum  of 
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competition  to  the  extent  feasible  and  practical, 
period,  end  of  sentence — 'Now  go  do  it.'"  (6:15) 

Despite  apparent  enthusiasm  for  this  strategy,  it  is  too 

early  to  determine  if  this  acquisition  strategy  will  prove 

feasible  since  it  assumes  several  decades  of  increasing 

government  regulation  and  oversight  can  be  easily  brushed 

aside . 


IV.  Interview  Findings 


a 
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Why  Do  Acquisition  Programs  Use  Concurrency? 

The  managers  I  interviewed  feel  that  when  a  program  is 
concurrent,  it  is  due  to  a  mandated  IOC  (Initial  Operational 
Capability)  date  which  forces  that  degree  of  concurrency. 

Two  managers  also  voiced  the  opinion  that  the  using  commands 
often  dictate  an  IOC  date  which  contains  some  built-in 
contingency  time;  therefore,  they  felt  that  concurrency  is 
sometimes  mandated  unnecessarily. 

Tnere  were  some  interesting  individual  opinions  voiced 
relating  to  this  question.  One  manager  said  that  concur¬ 
rency  is  sometimes  dictated  at  the  USAF  headquarters  level 
for  budgetary  reasons.  In  that  case,  he  said:  "...it 
appears  that  someone  in  the  financial  arena  wanted  to  save 
dollars,  he  thought,  by  going  into  production  an  additional 
year  earlier  and  having  less  inflation".  Another  manager 
who  had  some  previous  experience  on  the  operational  side 
mentioned  that  program  budget  fluctuations  which  result  from 
the  POM  cycle  .introduce  program  instability  which  makes 
previously  reasonable  IOC  dates  untenable  without  co  icur- 
rency.  Finally,  one  manager  wondered  out  loud  if  hi:  pro¬ 
gram  began  with  a  concurrent  program  philosophy  and  it 
evolved  into  a  unjustifiable  IOC,  rather  than  the  reverse. 
Overall,  however,  the  following  quotation  seems  to  sunmarize 
most  managers'  thoughts: 


fr. 


I  think  most  of  the  time  we  do  that  [concurrency], 
it  really  isn't  a  case  of  my  having  an  option  to 
do  it  or  not  do  it.  It  turns  out  to  be  a  corpor¬ 
ate  Air  Force  decision  as  to  whether  we  do  it  or 
not.  And  that  involves  a  lot  of  things  having  to 
do  with  wnen  we  need  it.  And  typically,  it's  the 
users  that  push  us  because  of  the  IOC  and  their 
genuine  needs.  We're  forced,  then,  to  do  concur¬ 
rency  rather  than  electing  it. 

All  of  these  comments  refer  to  planned  concurrency.  On 
any  program,  even  one  planned  to  be  completely  sequential, 
some  unplanned  concurrency  will  enter  into  the  program  as 
key  milescones  slip.  As  one  manager  noted,  "...tne  closer 
you  get  to  the  IOC... the  more  concurrency  you  start  building 
into  the  program." 

What  Advantages  Can  Concurrency  Produce? 

The  first  advantage,  and  the  only  one  mentioned  without 
fail,  is  tnat  concurrency  gets  a  system  out  in  the  field 
faster.  The  trade-offs  necessary  to  achieve  this  time 
savings  will  be  mentioned  under  the  disadvantages  section, 
but  no  one  disputed  tnat  concurrency  can  reduce  a  program 
schedule.  This  was,  very  often,  the  only  advantage  named. 

Second,  some  managers  suggested,  over  the  long  run  and 
using  a  strategic  viewpoint,  concurrency  can  produce  a  cost 
savings.  While  no  one  denied  that  a  concurrent  program  can 
be  expected  to  incur  a  proportionally  larger  number  of 
retrofits  (because  production  is  initiated  prior  to  comple¬ 
tion  of  testing),  some  managers  felt,  especially  in  periods 
of  high  economic  escalation,  that  concurrency  can  provide  an 
overall  cost  savings — provided  the  program  is  a  low  techni- 


cal  risk.  Other  advantages,  mentioned  by  only  a  few 
managers,  were: 


1 .  Concurrent  systems  are  less  obsolete  when 
fielded; 

2.  because  of  tneir  shorter  development  cycle, 
concurrent  weapon  systems  face  fewer  Congressional 
review  cycles; 

3.  low  technical  risk  concurrent  programs  are  an 
excellent  candidate  for  multi-year  funding; 

4.  operational  testing  begins  earlier  on  actual 
production  hardware; 

5.  concurrency  helps  maintain  a  manufacturing 
learning  curve; 

6.  tne  contractor  maintains  a  stable  workforce; 

7.  concurrency  allows  a  program  to  fit  within  a 
particular  political  window  of  opportunity; 

While  this  list  of  advantages  is  impressive,  it  must  be 

stressed  that  no  manager  advocated  the  wholesale  use  of 

concurrency.  No  one  recommended  its  use  on  high  technical 

risk  programs.  Some  managers  advocated  its  wide-spread  use. 

on  low  technical  risk  programs,  but  most  managers  favored 

its  use  in  specific  instances  wnere  fielding  a  weapon  system 

quickly  is  essential  to  counter  threats  to  the  national 

security  . 

What  Disadvantages  Can  Concurrency  Produce? 

The  managers  I  interviewed  indicated  that  the  overall 
effect  of  concurrency  is  an  increase  in  the  program's  level 
of  risk.  This  effect  most  often  manifests  itself  in 
increased  program  costs — especially  if  the  program's 


technical  risk  is  high  even  before  concurrency  is  initiated. 
As  previously  mentioned,  some  managers  felt  the  added  cost 
of  retrofits  was  balanced  by  the  reduced  economic  escalation 
and  shortened  contractor  support  time.  However,  as  one 
manager  put  it: 

...unless  you  took  the  strategic  view  of  the  pro¬ 
gram,  that  meaning:  you  took  the  view  that  you 
were  able  to  complete  a  program  in  less  time, 
unless  you  stood  above  it  and  said,  "I'm  finishing 
this  program  in  less  time  and  therefore  that's 
less  costly,"  you  wouldn't  recognize  the  costs 
saved.  Most  Program  Managers  aren't  in  a  position 
to  stand  above  their  program  and  view  the  global 
or  strategic  aspects  of  their  program. 

The  researcher  did  find  that,  in  general,  higher  level 

managers  were  more  lixely  to  mention  long  term  cost  savings 

relating  to  the  use  of  concurrency,  while  lower  level 

managers  focused  on  short  term  retrofit  costs.  Also, 

managers  actually  involved  in  the  retrofit  phase  of  a 

program  tended  to  focus  on  the  additional  rework  costs  of 

concurrency . 

Just  as  with  the  advantages,  a  whole  host  of  disad¬ 
vantages  were  also  named  by  individual  managers. 

1.  Concurrency's  success  may  be  dependent  on  the 
competency  of  the  prime  contractor. 

2.  it  allows  less  design  flexibility. 

3.  It  may  reduce  weapon  system  reliability. 

4.  "...you  nave  to  make  decisions  without  all 
tne  information  that  you'd  like  to  nave." 

5.  Tnere  is  often  a  lack  of  standardization  and 
commonality . 
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6.  Increased  training  requirements,  spares 
requirements,  and  support  equipment  costs. 

7.  It  creates  an  additional  work  load  on  people 
in  the  field. 

3.  The  program  faces  either  increased  manpower 
requirements,  or  you  burn  out  your  existing  human 
resources. 

9.  "...we  give  a  bad  impression  to  people  who 

are  overseeing  the  programs,  i.e.,  the  Congress, 
the  GAO  [Government  Accounting  Office],  and  others 
that  think  we're  short-cutting." 

10.  "We  tend  to  be  so  success  oriented  on  pro¬ 
grams  that  we're  willing  to  do  concurrently,  that 
we  under-plan  the  resources  needed  to  do  them. 
Particularly  in  terms  of  things  like  test  arti¬ 
cles." 

1 1 .  Concurrency  is  seen  as  a  disruption  to  an 
orderly  program — which  can  foster  an  atmosphere  of 
crisis  management. 

12.  The  user  may  receive  a  weapon  system  with  an 
initially  degraded  operational  capability,  and 
retrofits  may  also  delay  the  real  final  capabil¬ 
ity. 


13.  Concurrent  programs  receive  more  micro- 
management  by  multiple  levels  of  oversight  than 
sequential  programs. 

14.  Concurrency  as  an  adverse  effect  on  weapon 
system  supportability . 

No  manager  indicated  that  all  of  these  disadvantages  will 
actually  occur,  but  the  probability  of  these  outcomes  is 
increased  as  the  program's  degree  of  concurrency  and/or  the 
technology  risk  of  the  program  is  increased. 


How  Can  the  Risk  of  Concurrent  Acquisition  Be  Reduced? 

All  Program  Managers  who  addressed  this  question  named 
a  low  technical  risk  as  tne  key  ingredient  for  a  successful 
concurrent  program.  As  one  Program  Manager  said: 
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I  think  nigh  technical  risk  is  not  something  that 
you  want  to  go  concurrent  with.  If  you  want  to  do 
concurrency/  it  should  be  primarily  because  of 
schedule.  In  other  words,  the  technology  ought  to 
be  pretty  much  state-of-the-art,  an  integration 
type  effort,  versus  a  true  development . 

This  sentiment  was  echoed  by  another  manager  who  described 

his  first  ground  rule  for  a  concurrent  program: 

One,  you  can't  have  any  invention.  Whatever 
you're  going  to  put  into  the  program  has  to  be 
[already]  invented ... .And  if  you've  got  invention, 
it's  just  dumb  to  try  to  run  a  concurrent  program, 
because  you  just  can't  keep  up  with  it. 

during  the  interviews  I  found  that  some  concurrent  programs 
have  initiated  a  "risk  reduction”  phase,  or  in  another 
manager's  terminology,  a  "system  definition"  phase  within 
the  formal  demonstration/ validation  phase.  This  is  a 
relatively  short  contract  of  approximately  one  year  witn 
several  contractors  that  are  still  prime  candidates  for  full 
scale  development  and  production.  This  phase  assists  in 
early  definition  of  requirements  and  verifies  that  a  tech¬ 
nology  is,  in  fact,  proven.  It  may  consist  of  tests  of 
prototype  engines,  electrical  component  bread  boards,  and  so 
fortn.  The  objective  of  this  phase  is  to  reduce  technical 
risk  to  the  point  where  considerable  overlap  of  FSD  and  pro¬ 
duction  becomes  feasible.  It  should  be  noted  that  a  variant 
of  this  concept  (its  specific  application  in  conjunction 
with  concurrency  was  not  mentioned),  was  advocated  in  the 
recent  Packard  Commission  Report. 

Several  managers  also  cited  the  necessity  of  fixing  a 
program  baseline.  In  one  highly  concurrent  program,  its 


manager  said:  "you've  got  to  decide  what  our  minimum 

requirements  are,  and  see  if  the  technology  will  support  it, 

and  build  just  that.  And  do  not  change  it!"  Another 

manager  echoed  these  thoughts: 

I  believe  that  a  lot  of  programs  die  because  they 
spend  too  much  time  in  development,  and  that  we 
try  to  put  too  much  technology  in  too  soon.  And  I 
think  we  would  be  better  off  setting  a  technology 
baseline,  designing  the  system  to  that  baseline, 
and  then,  updating  it  periodically  using  the  tech¬ 
nology  as  it  becomes  available  and  is  proven,  as 
opposed  to  trying  to  stay  right  up  with  technol¬ 
ogy. 

Actually,  both  low  technical  risk  and  a  fixed  requirements 
baseline  amount  to  the  same  idea — a  concurrent  program  must 
have  a  stable  design  to  be  accelerated  successfully. 

A  successful  concurrent  program  requires  high  level 
concern  at  the  Secretary  of  Defense  level.  If  this  atten¬ 
tion  exists,  then  streamlined  management  practices  can  be 
initiated.  Several  instances  were  related  to  me  wnere  it 
was  necessary  to  appeal  directly  to  Secretary  Weinberger  to 
be  allowed  to  use  innovative  management  practices  which 
lower  levels  of  oversight  tried  to  stifle.  Just  as  an 
example,  one  manager  said: 

"...if  you're  in  a  rush,  you  don't  always  have  the 
time  to  wait  six  months  or  nine  months  to  get  a 
contractual  action  out  before  the  contractor  turns 
something  on.  We  did  a  lot  of  things  with  phone 
calls  and  letters  that  we  should  have  done  with 
contracting  actions. 

Other  innovations  were  program  specific,  but  tne  bottom  line 
of  these  practices,  as  they  were  related  to  me,  were  great 
savings,  in  terms  of  ooth  program  cost  and  schedule. 


However,  in  each  case,  a  regulation  existed  which  forbade 
such  actions.  Only  by  direct  appeal  to  the  Secretary  of 
Defense  were  these  managers  able  achieve  these  savings. 
Related  to  this  idea,  some  managers  also  mentioned  stream¬ 
lined  reporting  procedures,  since  one  major  frustration  very 
common  among  the  managers  I  interviewed  were  the  seemingly 
endless  layers  of  oversignt.  As  one  manager  put  it: 

"...it's  my  projection  that  by  the  year  2010,  we'll  have  one 
Program  Manager,  and  all  the  rest  of  the  Air  Force  will  be 
staff — helping  this  one  Program  Manager  with  bureaucracy." 

Also  relating  to  the  high  priority  of  a  concurrent 
program,  a  successful  concurrent  program  must  be  manned  with 
the  best/  most  experienced  people — especially  those  "that 
have  lived  through  a  retrofit  phase  of  production."  There¬ 
fore,  it  appears  that  the  number  of  programs  that  can  have  a 
high  degree  of  concurrency  is  limited  by  virtue  of  the 
relatively  limited  pool  of  top  notch  human  resources  with 
the  level  of  experience  necessary  to  man  these  programs. 

A  concurrent  program  must  plan  rigorous  testing.  One 
manager  recommended  tying  ground  testing  milestones  to  the 
Critical  Design  Review,  or  even  the  Preliminary  Design 
Review,  through  use  of  the  Statement  of  Work.  In  relation 
to  flight  tests  one  Program  Manager  said,  "if  you  going  to 
have  concurrency,  you  have  to  put  more  rigor  into  the  first 
flight  tests.  We're  gumping  in  fairly  neavy  in  terms  of 
test  objectives  and  taxing  the  capabilities  of  the  - ." 


This  Pro-gram  Manager  goes  on  to  say  that  "the  classic  DT&E 

l Developmental  Test  &  Evaluationj ,  followed  by  DT&E/IOT&E 

L Initial  Operational  Test  &  Evaluation],  followed  by  OT&E 

[Operational  Test  &  Evaluation]  become  rather  blurred"  [on  a 

concurrent  program].  In  this  particular  program,  the  first 

flight  will  incorporate  both  developmental  and  operational 

test  and  evaluation  objectives.  This  manager  also  added 

that  besides  rigorously  testing  the  prototypes, 

...if  you’re  going  to  make  a  production  decision 
based  on  the  results  of  very  limited  flight  test¬ 
ing,  the  vehicles  have  to  be  really  representa¬ 
tive,  or  as  close  as  you  can  make  them  to  the 
final  configuration. 

And  when  early  funding  cuts  occur  early  in  the  program,  the 
resources  for  the  test  articles  must  be  protected.  Several 
Program  Managers  felt  this  was  a  major  problem  for  a  concur¬ 
rent  program.  Because  the  time  for  testing  prior  to  making 
a  production  decision  is  very  limited,  a  full  complement  of 
test  articles  is  essential  to  make  an  intelligent  production 
decision. 

A  close  working  relationship  between  the  SPO  and  the 
contractor  is  essential.  This  factor  was  the  most  often 
cited  factor  besides  a  low  technical  risjc.  Because  of  the 
tight  schedule,  disagreements  between  the  Air  Force  and  the 
prime  contractor,  or  even  an  attitude  by  the  contractor  to 
go  strictly  by  the  regulations,  can  do  irreparable  damage  to 
the  SPO's  effort  to  reach  IOC.  Although  the  necessity  of 
having  this  close  working  relationship  may  appear  obvious, 
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one  manager  of  a  major  program  was  very  alarmed  about  an 
attitude  he  felt  was  becoming  more  prevalent  among  Air  Force 
personnel : 

We've  got  guys  running  around  in  their  shiny  armor 
with  a  white  horse  trying  to  spear  all  of  the  con¬ 
tractors  because  [they  think]  they're  incompet¬ 
ent....  You  know,  you  can  accomplish  a  hell  of  a 
lot  more,  by  going  and  working  with  the  contractor 
to  solve  his  proolems,  than  running  around  and 
branding  him  no  good  or  criminal.  I  don't  like 
the  attitude  that's  developing  in  the  Air  Force 
and  the  DOD  that  all  contractors  are  criminal. 

Also,  a  few  managers  felt  that  the  form  of  contract,  whether 
cost  plus  incentive  or  firm  fixed  price,  can  hinder  close 
working  relationship  between  the  Air  Force  and  the  contrac¬ 
tor.  Because,  under  a  fixed  price  contract,  the  contractor 
assumes  a  large  proportion  of  the  risk,  formerly  helpful 
contractors  may  interpret  a  narrower  scope  to  their  contract 
responsibilities  than  Air  Force  personnel  feel  is  justified. 
As  one  manager  related  who  had  lived  under  both  a  develop¬ 
ment  cost  plus  and  then  a  production  fixed  price  contract: 

...you  would  have  thought  you  were  dealing  with  a 
different  company.  The  same  one  that  was  willing 
to  do  anything  you  asked  to  solve  a  problem  in  the 
beginning,  suddenly  started  stonewalling. 

He  also  related  his  experience  on  another  firm  fixed  price 

contract : 

...I  spent  inordinate  amounts  of  time  after  I  got 
there  trying  to  coerce  the  contractor  into  fixing 
tnings.  And  he  would  spend  as  much  time  trying  to 
prove  that  there  wasn't  anything  wrong  as  there 
would  be  if  he  just  accepted  the  problem  and  went 
out  and  fixed  it. 
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However,  discussion  of  favorable  contract  types  for 

concurrency  is  probably  a  moot  point,  since  it  is  unlikely 

tnat  any  change  will  come  about  due  to  the  present 

acquisition  environment: 

I  don't  like  fixed  price  contracts  for  concur¬ 
rency,  but  that  seems  to  be  the  philosopny.  We've 
talked  about  going  cost  plus  on  a  few  of  our  pro¬ 
grams  (cost  plus  incentive  fee,  cost  plus  incen¬ 
tive  with  award  fee),  and  there's  a  very  strong 
negative  attitude  for  that  in  the  AFSC  and  ASD 
community.  They  want  to  see  fixed  price. 

Therefore,  while  a  firm  fixed  price  production  contract  must 

be  assumed  for  concurrent  programs,  it  does  not  seem  to  be  a 

problem  specifically  related  to  concurrency,  since  fixed 

price  contracts  are  applied  across  the  entire  spectrum  of 

ASD  programs.  Several  Program  Mangers  of  highly  concurrent 

programs  did  not  indicate  any  problems  relating  to  firm 

fixed  price  contracts.  The  overwhelming  emphasis  for  a 

concurrent  program,  however,  is  to  promote  cooperation 

between  the  Air  Force  and  the  contractor.  As  one  manager 

summarized : 

...you've  got  to  work  as  a  team.  You  can't  have  a 
we-they  attitude.  You  know,  the  Air  Force  pro¬ 
duces  nothing.  We  build  absolutely  nothing.  We 
don't  do  a  damn  thing.  Our  whole  industry  sup¬ 
ports  us.  And  if  you  reach  a  point  where  you're 
in  an  adversarial  role  with  your  contractor,  you 
lose.  Just  automatically,  you're  going  to  lose. 

As  a  final  note,  all  of  the  managers  I  interviewed  made 

the  assumption  that  any  concurrent  program  is  driven  to 

concurrency  by  an  IOC  date  which,  in  turn,  is  driven  by  the 

tnreat.  As  one  Program  Manager  concluded:  "there's  got  to 


be  an  end  result  for  why  you’re  doing  it.  Just  to  start  out 
and  do  concurrency,  I  think,  would  be  dumb." 

How  Do  Contractors  Feel  About  the  Use  of  Concurrency? 

Very  few  managers  had  ever  directly  questioned  contrac¬ 
tor  personnel  about  their  feelings  concerning  the  use  of 
concurrency,  but  basing  their  opinions  upon  contractor 
actions  and  proposals,  tnere  seemed  to  be  a  consensus  thac 
contractors  favor  its  use.  Of  course,  there  was  one 
dissenter  among  the  managers  I  interviewed:  "Nobody  likes 
it  [concurrency].  Nobody  likes  it  at  all.  But  they  signed 
up  to  a  contract  which  had  an  accelerated  schedule." 

Another  manager  also  indicated  that  one  portion  of  the 
contractor's  organization  would  oppose  its  use  even  though 
the  organization  as  a  whole  might  support  it: 

...they've  got  people  who  nate  concurrency  as  much 
as  we  do.  And  that  would  be  the  people  on  the 
manufacturing  side.  Tney  get  themselves  all  set 
up  to  manufacture  wnat  they  think  is  the  design 
and  all  of  a  sudden,  it's  a  different  design.  And 
then,  who  gets  rapped?  The  manufacturing  side  of 
the  house. 

All  of  the  other  managers  indicated  either  indifference  or 
support  by  the  contractor. 

How  Do  the  Using  Commands  Feel  About  the  Use  of  Concurrency? 

Of  the  managers  I  interviewed  who  felt  qualified  to 
answer,  they  were  agreed  tnat  the  user  is  often  caught  up  in 
unrealistic  expectations.  In  the  eyes  of  these  managers, 
the  using  commands  expect  rigorous  IOC  dates  to  be  met  with 
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no  loss  of  operational  capability  for  the  weapon  system  when 

it  is  first  fielded.  Consequently,  the  users  may  initially 

approve  of  tne  use  of  concurrency  to  get  the  system  out  in 

the  field,  but  are  unprepared  for  the  inevitable  retrofits 

that  follow.  The  following  remarks  illustrate  this  finding. 

...they  want  it  as  soon  as  they  get  it,  and  then, 
as  soon  as  they  get  it,  they  start  complaining 
about  it.  I  think  they  like  concurrency  until 
tney  get  it,  and  then  after  they  get,  they  don't 
like  it  anymore. 

...so  they  usually  go  catatonic  [when  faced  with  a 
highly  concurrent  program]. 

One  manager  who  did  have  operational  experience  dealing  with 
the  introduction  of  new  programs  tended  to  support  tne 
consensus  of  the  other  managers;  he  said:  "the  user  hates 
concurrency ... .The  user  doesn't  like  concurrency,  because 
concurrency  always  ends  up  that  he  doesn't  have  what  he 
needs  when  he  needs  it." 

How  Should  Interim  Contractor  Support  Be  Employed  on  a 
Concurrent  Program? 

Some  managers  feel  tne  Air  Force  goal  of  implementing  a 
complete  blue  suit  weapon  system  support  capability  by  the 
IOC  date  is  unattainable  and  unrealistic — especially  on  a 
concurrent  program.  They  recommended  a  planned  use  of  ICS 
until  a  true  organic  support  capability  can  be  generated. 

One  manager  mentioned  that  a  proposal  is  circulating  around 
ASD  that  a  date  separate  from  the  IOC  date  should  be  estab¬ 
lished  as  the  initial  organic  support  capaoility  date.  This 
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could  be  an  important  first  step  toward  a  more  flexible 
support  policy. 


What  Are  the  Managers'  Overall  Appraisals  of  Concurrency? 

The  managers  I  interviewed  had  serious  differences  of 

opinion  about  concurrency.  Five  managers  expressed  negative 

opinions  concerning  its  use.  The  following  statements  are 

representative  of  these  opinions: 

If  we  had  to  do  this  program  again,  we  would  have 
no  choice,  but  it's  better  not  to  be  concurrent  or 
to  have  the  minimal  amount  of  concurrency  as 
you're  able  to,  as  long  as  you  can  do  that  and 
stiil  meet  your  objectives. 

I  don't  really  think  it's  good.  I'm  one  of  the 
advocates  that  it  [weapon  system  acquisition] 
should  be  done  sequentially. 

I  don't  want  to  do  it  [ concurrency ]  again.  That 
is,  it's  been  a  headache.  I've  had  to  drive  my 
people  and  I've  had  to  drive  myself  in  order  to. 
accomplish  this  end  goal. 

The  rest  of  the  managers  expressed  qualified  support  for  the 

use  of  concurrency  provided  its  application  is  necessary  to 

counter  perceived  threats  to  the  national  security: 

You  have  to  accept  a  certain  amount  of  risk.  If 
you  don't  have  seme  concurrency,  I  don't  think 
you'll  ever  get  a  program  fielded.  If  you  solved 
all  the  problems  before  you  went  into  production, 
you'd  never  get  into  production — because  there  are 
always  going  to  be  problems. 

i  cnink  r.h-.r.  concurrency  has  gotten  a  bad 
rap.  In  this  business,  you've  got  to  have  some 
concurrency . 

Well,  it's  challenging,  but  it's  probably  th?  best 
way  to  get  new  capabilities  in  the  field. 


V.  Conclusions  and  Recommendations 

Introduction 

The  following  conclusions  and  recommendations  are  based 
on  the  researcher's  literature  review  as  well  as  interviews 
of  ASD  managers  conducted  during  this  research  effort. 

8ecause  of  the  length  of  the  current  weapon  system 
acquisition  cycle,  some  degree  of  development  and  production 
phase  overlap  is  now  routine  management  practice  for  most 
major  ASD  acquisition  programs;  however,  a  concurrent 
strategy  requires  the  following  tradeoff:  as  the  degree  of 
concurrency  increases,  additional  risk  is  incurred  which  may 
result  in  higher  program  costs  and  less  capable  weapon 
systems.  This  increased  risk  exposure  can  be  alleviated 
through  use  of  special  management  practices  which  early 
concurrent  programs  first  employed.  These  principles  (See 
Research  Question  Two)  focus  on  a  small  and  highly  capable 
program  office  which  has  been  freed  from  the  multiple  layers 
of  oversight  which  constrain  mainstream  acquisition 
programs . 

The  new  "streamlining"  initiative,  supported  by  the 
Defense  Science  Board  and  the  Packard  Commission,  appears  to 
involve  a  return  to  some  of  the  management  practices  of  the 
original  concurrent  programs.  Judging  from  previous 
concurrent  acquisition  failures,  this  new  streamlining 
approach  should  be  applied  to  a  limited  number  of  programs. 


and  only  in  cases  where  a  significant  national  security 
threat  exists.  These  special  programs  must  be  shielded  from 
interference  from  Congress,  and  more  importantly,  from 
interference  within  the  Department  of  Defense.  This  will 
require  exceptional  program  autonomy  and  a  consequent 
reliance  on  highly  capable  Air  Force  and  contractor 
personnel.  Finally,  if  a  significant  degree  of  schedule 
compression  is  employed  on  these  programs,  technical 
"invention"  must  be  purposely  limited  and  competition 
between  alternative  technical  approaches,  and  between 
contractors  should  be  encouraged. 

Research  Question  One 

The  first  objective  of  the  literature  review  was  to 
determine  "why  was  concurrency  originally  employed  in  the 
Air  Force  Ballistic  Missile  Program?" 

Concurrency  was  initiated  because  of  the  impending 
threat  of  a  potential  "missile  gap"  (the  Soviet  Union 
becoming  the  first  nation  to  possess  nuclear  armed  ICBMs). 
Because  the  existing  military  acquisition  process  had 
reverted  back  to  a  sequential  "peacetime"  acquisition 
strategy  after  World  War  Two,  the  Neumann  Committee 
concluded  that  it  was  necessary  to  take  the  ballistic 
missile  program  "outside"  the  conventional  acquisition 
process  using  management  principles  similar  to  that  of  the 
earlier  Mannattan  Project. 


Research  Question  Two 


The  second  objective  was  to  determine  "why  was  concur¬ 
rency  initially  so  effective?" 

In  its  original  application,  concurrency  satisfied  the 
four  requirements  for  a  successful  crash  program: 

1 .  A  significant  threat  demanding  a  rapid 
response . 

2.  Great  latitude  in  managing  the  crash  program. 

3.  Unrestricted  resources  to  draw  upon. 

4.  Very  close  cooperation  between  the  Program 
Office  and  highly  motivated  contractors. 

Because  of  a  significant  perceived  tnreat  from  the  Soviet 

Union,  a  consensus  formed  within  the  United  States  to  do 

whatever  was  necessary  to  field  an  effective  ballistic 

missile  system  as  rapidly  as  possible — this  decision 
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(normally  only  possible  in  wartime),  made  the  other  three 
factors  feasible.  Great  management  latitude  or  program 
autonomy  allowed  both  innovative  management,  and  just  as 
important,  a  sheltering  from  second-guessing  intermediate 
levels  of  oversight  that  frustrate  timely  and  effective 
decision  making.  Unrestricted  resources  (or  at  least, 
freedom  from  cutbacks  in  programmed  funds),  allowed  alterna¬ 
tive  approaches  to  be  pursued  for  systems  and  subsystems 
that  posed  uncertain  technical  risk.  Finally,  an  attitude 


of  trust  existed  between  the  Air  Force  and  program  contrac¬ 
tors  which  allowed  streamlined  procedures  to  be  practiced. 


t 
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Research  Question  Three 


The  third  objective  was  to  determine  "why  was  concur¬ 
rency  blamed  for  cost  overruns  in  the  1960s?" 

Following  the  success  of  the  Air  Force  Ballistic  Mis¬ 
sile  Program/  the  heavily  publicized  strategy  of  concurrency 
became  a  model  for  other  programs  to  emulate  during  the 
1960s.  However/  when  concurrency  was  applied  to  acquisition 
programs  within  the  conventional  procurement  process,  it 
often  signified  little  more  than  overlap  of  development  and 
production  without  regard  to  the  program's  technical  risk. 
The  foremost  problem  encountered  with  this  new  application 
was  the  lack  of  a  significant  perceived  threat  which  would 
mobilize  a  national  consensus  "to  do  whatever  is  necessary 
to  field  a  system."  Since  schedule  compression  merely 
increased  these  programs'  acquisition  risks  without  the 
corresponding  risk  reductions  that  accompany  the  original 
concurrency  concept,  many  programs  employing  this  compres¬ 
sion  encountered  problems  which,  in  the  uncertain  political 
environment  of  the  1960s,  resulted  in  a  number  of  budget 
cutbacks  or  even  outright  cancellations. 

Research  Question  Four 

The  fourth  objective  was  to  determine  "why  did  the 
Defense  Science  Board  advocate  the  use  of  concurrency  in 
weapon  system  acquisition?" 

The  Defense  Science  Board  recognized  that  the  United 
States's  military  acquisition  times  were  inexorably  stretch- 
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ing  oat  and  the  DoD  was  losing  the  ability  to  react  success¬ 
fully  to  the  rapidly  changing  threat  environment.  Through  a 
review  of  a  large  number  of  both  civilian  and  military 
acquisition  programs,  the  Board  found  that  concurrency  was 
not  linked  to  lower  quality  systems.  Consequently,  the 
Defense  Science  Board  recommended  a  flexible  policy  of 
prototyping  which  replaced  the  rigid  system  of  double¬ 
prototyping  (an  initial  prototype  airframe  competition 
followed  by  production  prototypes  during  FSD) ,  which  David 
Packard  referred  to  as  "fly-before-buy." 

Research  Question  Five 

The  fifth  objective  was  to  determine  if  "the  employment 
of  concurrency  has  changed  since  the  concept  originated  in 
the  1950s?" 

When  the  concurrency  strategy  was  employed  on  the  Air 
Force  Ballistic  Missile  Program,  it  was  a  specialized 
management  strategy  suitable  only  for  the  highest  priority 
procurements  which  result  from  a  significant  threat  to 
national  security.  However,  in  the  1960s,  concurrency  was 
applied  to  the  conventional  acquisition  process  and  the  term 
came  to  mean  simple  overlap  of  development  and  production. 
While  this  generic  concurrency  continues  to  be  employed  in 
the  1980s,  the  term  "streamlining,"  which  is  an  outgrowth  of 
the  Lockheed  Skunk  Works  philosophy,  has  entered  into  the 
acquisition  vocabulary  and  may  more  fairly  represent  the 
original  concept  of  concurrency. 


Research  Question  Six 

The  first  interview  objective  was  to  determine  "why  is 
concurrency  employed  in  today's  Air  Force  acquisition 
programs?" 

Concurrency  is  employed  for  two  basic  reasons.  Planned 
concurrency  is  utilized  in  the  original  planning  of  an 
acquisition  program,  normally  in  response  to  directed  IOC 
dates,  which  are  determined  at  the  Secretary  of  Defense  and 
Air  Staff  level.  Unplanned  concurrency  is  used  during  the 
course  of  the  development,  when  unknown  unknowns  occur  which 
cause  slips  in  the  original  program  schedule;  additional 
compression  is  therefore  employed  to  achieve  the  program's 
directed  IOC  date. 

Research  Question  Seven 

The  second  interview  objective  was  to  determine  "how 
does  concurrency  affect  acquisition  programs?" 

The  use  of  concurrency  increases  the  risk  of  an  acqui¬ 
sition  program  in  order  to  acnieve  an  earlier  IOC  date. 
Normally,  this  risk  is  evidenced  through  increased  program 
costs  relating  to  the  retrofit  of  already  produced  systems 
and  also  reduced  initial  supportability  of  the  overall 
weapon  system.  In  an  environment  of  high  inflation,  this 
increased  rework  cost  may  oe  balanced  out  in  the  long  run, 
but  from  a  Program  Manager's  vantage  point,  concurrency 
creates  a  program  disruption  which  can  lead  to  an  atmosphere 
of  crisis  management. 


Research  Question  Eight 


The  third  interview  objective  was  to  determine  "what 
factors  can  reduce  the  acquisition  risk  of  concurrency?" 

Limiting  the  technical  risk  of  the  acquisition  program 
by  avoiding  invention  during  the  development  was  identified 
as  a  key  ingredient  for  success  on  a  program  with  a  high 
degree  of  concurrency. 

Program  baselining  and  Secretary  of  Defense  attention 
were  also  named  as  important  factors  which  can  "shelter"  a 
program  from  instability. 

Human  resources  are  a  priority  for  a  concurrent 
program;  several  managers  felt  that  top  quality,  experienced 
personnel  were  essential  to  program  success,  as  well  as  a 
close  working  relationship  between  the  System  Program  Office 
( 3P0)  and  the  program's  contractors. 

Finally,  the  managers  who  were  interviewed  indicated 
that  concurrency  must  be  driven  by  an  Initial  Operational 
Capability  (IOC)  date  which  is,  in  turn,  driven  by  a  threat 
to  national  security. 


Re search  Question  Nine 

The  fourth  interview  objective  was  to  determine  "what 
do  managers  actually  involved  in  concurrent  programs  think 
about  the  strategy? 

Fifteen  of  the  twenty  managers  interviewed  expressed 
qualified  support  for  the  use  of  concurrency,  provided  its 


application  is  necessary  to  counter  perceived  threats  to  the 
national  security.  The  other  five  managers  expressed  dis¬ 
pleasure  with  the  strategy  and  favored  moving  to  a  more 
sequential  acquisition  process. 

Recommendations 

The  researcher  offers  three  recommendations  for  further 
study  based  on  the  findings  of  this  research.  While  this 
study  focused  on  Air  Force  Systems  Command  acquisition  per¬ 
sonnel,  it  is  likely  that  the  majority  of  Air  Force  Logis¬ 
tics  Command  personnel  demonstrate  a  different  perspective 
regarding  the  use  of  concurrency  in  Air  Force  acquisition 
programs.  A  study  documenting  their  opinions  on  the  use  of 
concurrency  and  their  recommendations  of  how  to  limit  the 
supportability  risk  of  concurrency  is  one  possibility. 

A  second  recommendation  for  study  is  to  research  the 
effect  of  Interim  Contractor  Support  on  concurrent  programs 
and  to  determine  the  length  of  time  for  which  ICS  should  be 
funded . 

A  third  and  final  recommendation  is  to  study  the  new 
"streamlining"  acquisition  strategy  in  the  form  of  indi¬ 
vidual  program  case  studies. 


Note:  The  following  paragraphs  are  quotations  from 
interview  transcripts  unless  material  is  bracketed. 


Why  Do  Acquisition  Programs  Use  Concurrency? 

Manager  # 1 . 

So  concurrency  is  a  management  tool  that's  necessitated  by 
reaction  to  other  management  events  or  realities  that  you 
have  to  deal  with. 


***** 

Manager  #2. 

The  pressure  that  one  always  faces  is,  the  user  wants  it. 
Once  you  make  a  decision  to  start  a  development  program,  an 
acquisition  program,  the  user  wants  it  out  there  tomorrow. 

***** 

Manager  #3. 

It's  something  the  standard  program  shouldn't  do,  but  when 
you  have  schedule  problems  as  we  had,  not  problems,  we  had 
commitments. . .that  we  would  have  equipment  there  on  a 
certain  date,  and  if  the  only  way  to  meet  that  date  is 
concurrency — then  you  do  it. 

I  think  it's  probably  forced  upon  most  programs  to  some 
extent ... .but  I  can  see  where  you  start  down  a  road  to  meet 
an  IOC  [Initial  Operational  CapabilityJ ,  and  as  you  go  down 
the  road,  then  everything  slips  except  the  IOC.  And  the 
closer  you  get  to  IOC,  because  those  tend  to  be  hard  dates, 
the  more  concurrency  you  start  building  into  the  program. 

***** 

Manager  #4. 

Somebody  wants  to  stay  on  schedule,  so  you  weigh  the  risks 
of  concurrency,  and  make  a  decision. 

***** 

Manager  #5. 

So  I  think  it  got  to  be  matter  of,  they  got  into  it 
[development],  and  said,  "shoot,  if  we're  ever  going  to  mak 
this  work,  we're  gonna  have  to  go  ahead  and  start  using  it- 


whether  it's  ready  or  not."  So  I  don't  think  it 
[concurrency]  was  planned  from  the  beginning  of  the  program, 
it  was  something  the  program  evolved  into. 


Manag  e  r  #  6 . 

Considering  all  the  constraints  you  have  [as  a  Program 
Manager] — you  really  don't  have  a  lot  of  choice.  I  assume 
that  they  would  do  it  again  [plan  a  concurrent  program 
schedule] . 


Manager  #7. 

I  tninK  most  of  the  time  we  do  that  [concurrency],  it  really 
isn't  a  case  of  my  having  a  option  to  do  it  or  not  do  it. 

It  turns  out  to  be  a  corporate  Air  Force  decision  as  to 
whether  we  do  it  or  not.  And  that  involves  a  lot  of  things 
having  to  do  witn  when  we  need  it.  And  typically,  it's  the 
user  that  push  us  because  of  the  IOC  and  their  genuine 
needs.  We're  forced,  then,  to  do  concurrency  rather  than 
electing  it. 

***** 

Manager  #8. 

The  primary  driver  is  if  it's  necessary  to  field  it  quickly. 


Manager  *11. 

Normally  wtien  a  new  system  is  identified,  they  usually 
identify  a  need  date  for  it  too.  And  that's  the  kind  of 
tning  that  drives  concurrency. 


Manager  #12. 

Tne  degree  of  concurrency  is  forced. 


Manager  *13. 

...a  certain  scnedule  has  been  directed  on  us.  In  order  to 
meet  that  schedule,  a  certain  amount  of  concurrency  is 
required  to  do  that. 


Manager  #15 


Concurrency  comes  about  for  a  lot  of  reasons.  Perhaps 
achieving  an  IOC  means  that  you  have  to  start  and  finish  a 
program  very  quickly.  And  because  you  have  just  a  short 
program  life  span,  you  must  do  both  development  and 
production  at  the  same  time. 

[This  manager  also  mentioned  pre-planned  improvements  as 
another  reason  concurrency  is  employed  later  in  a  program 
life  cycle. j 


Manager  #16. 


*  *  a  a  * 


LA  major  command],  more  or  less,  mandated  the  use  of 
concurrency . 


*  *  *** 

Manager  #17. 

I  think,  in  a  general  case  within  my  experience,  a  directed 
IOC  is  what  forces  a  degree  of  concurrency. 

A  A  AAA 

Manager  #18. 

...so  often,  we  have  directed  schedules.  It  takes  us, 
either  a  very  long  time  to  get  to  the  point,  through  the 
conceptual  stage,  where  we  can  finally  get  into  the  FSD 
[Full  Scale  Development];  and  we  shorten  the  time  we  have 
to  finally  get  operational;  or  to  get  the  support  you  need 
from  the  user,  from  the  HQUSAF,  from  AFLC,  and  from 
Congress,  it's  difficult  to  project  out  a  lengthy  program 
that  has  no  concurrency. 

But  there's  a  lot  of  pressure  to  move  from  FSD  and  turn  on 
production  while  you're  testing — political  pressure.  The 
program  may  be  lost  if  you  don't  do  that. 

We're  being  pushed  to  do  concurrency  because  of  shortened 
time  frames. 


A  A  A  A  A 

Manager  #19. 

But  I  really  think  the  IOC,  or  the  need  for  the  technology 
has  got  to  be  the  driver  [for  the  use  of  concurrency]. 


Manager  *20. 

Cpt  Foote.  Your  current  use  of  concurrency  was  driven  by 
Congress? 

Manager.  Yes....tnis  was  directed  on  us. 

***** 
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Appendix  B:  Measurement  Question  Two 
Note:  The  following  paragraphs  are  quotations  from 
interview  transcripts  unless  material  is  bracketed. 


What  Advantages  Can  Concurrency  Produce? 


Manager  #1 . 

[This  manager  focused  solely  on  its  time  savings.] 


Manager  #2. 

If  you  sequentially  do  all  of  the  tasks  that  are  set  before 
you,  it  just  takes  too  long  to  field  a  weapon  system. 

So  certainly  it's  going  to  save  money.  Every  month  that 
you've  got  the  doors  open  and  you've  got  a  contractor  under 
contract,  it's  big  dollars. 


Manager  #3. 

Obviously,  we  made  the  schedule. 


Manager  #4. 

I  think  it  offers  the  benefit  of  the  user  being  more  likely 
to  crank  in  some  changes  that  are  really  needed  from  his 
perspective — if  it's  done  right.  And  that  is,  if  those  low 
rate  production  units  that  he  has  out  in  the  field,  if  he's 
permitted  the  flexibility  of  getting  changes  into  the  next 
decision,  the  high  rate  units,  then  I  think,  in  the  long 
haul,  you'll  get  a  better  product. 

[This  manager  also  mentioned  reducing  the  program  schedule 
and  more  effective  testing  through  use  of  the  low  rate 
production  decision.] 


Manager  #5. 


So  it  did  put  the  concept  in  the  field  sooner  by  going 
concurrent . 


The  actual  using  of  the  product  and  having  a  floating 
baseline,  I  think,  helped  us  develop  a  better  product. 


Manager  #6. 


***** 


Well,  your  first  answer,  of  course,  is  it  gets  something  in 
the  field  quickly  to  meet  a  threat. 

I  guess,  when  you  compress  things,  also,  you  tend  to  not  be 
so  obsolete  once  it  gets  to  the  field.  So  it  has  a  more  us¬ 
able  life — presuming  that  it,  to  some  degree  at  least,  or  a 
sufficient  degree — does  the  job  that  it  was  intended  to  do. 


Manager  #7. 


***** 


I  think  it  [concurrency]  can  produce  a  time  savings... 

Well,  I  think  in  those  programs  where  schedule  is  the 
primary  consideration,  and  not  the  technical  aspect,  then  I 
think  there's  cost  benefits  to  be  achieved. 


***** 

Manager  #8. 

It  really  does  get  it  in  the  field  more  quickly.  And  in  the 
long  run,  it  will  give  you  some  problems  and  if  you  can 
manage  those  problems  correctly,  it  will  allow  you  to  get  a 
system  fielded  more  cheaply. 


*  *  *** 

Manager  #9. 

In  a  higher  risk  program,  like,  let's  say  a  F-15  or 
something  of  that  sort,  concurrency  has  been  necessary  in 
order  to  maintain  a  learning  [curve]  in  building  the 
airplanes  and  getting  started. 


You  maintain  a  workforce  in  place. 

It  hit  it  it 


Manager  #10. 

So  you  get  a  faster  limited  capability  during  the  concurrent 
program . 


...you  get  operational  testing  earlier.  They're  out  there 
flying  the  beasts. 


*  *  *** 
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Manager  #11. 


Like  I  said  earlier,  there's  no  way  you  can  eliminate  all 
concurrency.  Because  if  you  did  that,  then  you  would 
probably  never  get  anything  built.  You'd  stretch  out  your 
programs  for  ever  and  ever. 


Manager  #12. 

As  long  as  we  continue  to  have  inflation,  the  earlier  you 
can  buy  it,  the  cheaper  it  is. 


Manager  #13. 

Well,  when  you  save  time,  you  save  money.  And  you  get  a 
contractor  out  spending  $20  million  a  month,  you  save  a  few 
months  and  you  save  yourself  quite  a  bit  of  money. 

Getting  it  right  the  first  time  may  tend  to  draw  out  a 
program  so  long  that  it  may  never  withstand  all  the  budget 
cycles  in  Congress — and  you  may  never  get  it  at  all. 


***** 


Manager  #14. 


You  can  save  beaucoup  dollars. 

...if  you  can  get  a  system  into  production  during  one 
administration,  it  sure  helps.  And  if  you  have  to  go 
through  multiple  administrations,  and  you  get  the  on-again, 
off-again  defense  attitude,  it  sure  as  hell  make  the  program 
hard  to  manage  and  hard  to  run. 


Manager  #13. 

In  a  sense,  concurrency  saves  money  when  you  can  start  and 
finish  a  program  in  less  time. 


***** 


Manager  #16. 


Cpt  Foote.  By  employing  concurrency  then,  even  though  you 
did  incur  some  slippage,  did  it  produce  some 
time  savings  over  a  normal  sequential  program? 

Manager.  It  certainly  did.  One  thing  that  has  never 
changed  is  the  end  date  on  the  program. 

***** 
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Manager  #17. 

Every  year,  you  know,  there's  a  big  budget  crunch  and 
there's  a  different  set  of  priorities  and  the  longer  you 
stretch  it  out,  the  more  at  risk  the  program  is.  So  I  guess 
I  tend  to  support  the  notion  that  you  ought  to  decide  what 
you  need  to  do  and  do  it. 

...the  longer  you  stretch  out  a  program,  the  more  you  get  in 
terms  of  [key  personnel]  turnover  rate--they  multiply. 

LThis  manager  also  mentioned  achieving  an  earlier  IOC  and 

reduced  obsolescence  in  threat  sensitive  weapons  systems  as 

additional  advantages  of  concurrency.] 

***** 

Manager  #18. 

I  tnink  it's  had  the  effect,  at  least  on  the  surface,  of 
snortening  the  schedule. 

***** 

Manager  #19. 

[This  manager  cited  a  reduced  schedule  as  his  sole  perceived 
advantage. j 

*  *  *** 

Manager  #20. 

The  primary  benefit  is  being  able  to  put  something  out  in 
the  field  sooner. 


Note 


Appendix  C:  Measurement  Question  Three 
:  The  following  paragraphs  are  quotations  from 
interview  transcripts  unless  material  is  bracketed. 


What  Disadvantages  Can  Concurrency  Produce? 

Manager  #1 . 

Well,  the  ultimate  measure  is  high  cost,  both  in  terms  of 
dollars  and  in  terms  of  manpower.  And  also  in  loss  of 
availability  of  weapon  systems.  And  secondarily,  a  lack  of 
flexibility  in  weapon  systems.  And  a  lack  of 
standardization,  a  lack  of  commonality,  increased  training 
requirements,  increased  spares  requirements,  increased 
technical  data  requirements,  increased  replenishment  of 
spares  and  support  equipment  costs. 

So  it  has  a  great  adverse  effect  on  supportability . 

***** 

Manager  #2. 

We  had  some  pressure  to  shorten  the  development  time,  to  get 
to  flight  test  sooner.  We  categorically  resisted  squeezing 
the  development,  because  again,  like  the  old  saw,  if  you 
want  it  bad,  you're  going  to  get  it  bad. 

***** 

Manager  #3. 

I'm  sure  it  cost  us  more,  but  I  don't  know  what  it  would 
have  cost  us  if  we  had  just  gone  through  a  normal  program. 

Once  you  get  the  stuff  fielded,  you  have  to  go  back  and  fix 
it  to  make  it  the  way  you  want  it  to. 

We  had  a  number  of  configurations  in  the  field... 

We're  a  little  less  reliable  than  we  should  be,  and  we  are 
having  to  spend  quite  a  bit  of  money  to  go  back  and  identify 
improvements  that  we  need  to  improve  reliability,  then  go 
back  and  make  the  fixes.  And  it  is  putting  questions  in  a 
lot  of  people's  minds  on  the  capability  of  the  system. 


Manager  #4. 


...in  the  long  haul,  statistically,  across  all  of  those 
[concurrent]  programs,  I  think  you'd  find  that  it  would  cost 
you  a  fair  amount  more.  Because  you  have  to  be  continually 
making  major  changes  at  the  end  of  the  program. 

***** 

Manager  #5. 

We  got  called  "dumb"  on  the  production  programs,  and  the 
cost  increased  on  the  production  programs  because  we  were 
constantly  changing  baselines  of  hardware  and  software. 

***** 

Manager  #6. 

I  think  what  suffers  when  you' re  concurrent  is  your 
reliability. 

When  you  do  things  quickly,  sometimes  you  have  to  make  not 
the  most  optimum  decision — that  might  drive  up  the  costs. 

***** 

Manager  #7. 

The  drawbacks,  if  there  is  any,  is  perhaps  tnat  we  give  a 
bad  impression  to  people  who  are  overseeing  the  programs 
(i.e.,  the  Congress,  the  GAO  [Government  Accounting  Office], 
others  that  think  we're  shortcutting  and  don't  understand 
the  benefits  that  we  really  do. 

Concurrent,  in  itself,  implies  an  urgency,  and  an  urgency 
implies  less  well  thought  out  programs ... .Even  on  concurrent 
programs,  we  really  need  to  make  sure  we've  got  our  feet  on 
the  ground  before  we  go  into  that  first  contract,  and  we 
don't  typically  do  that  well. 

***** 

Manager  #8. 

Well,  the  major  problem  is  that  we're  still  testing  things 
while  we're  producing  aircraft. 

...there's  a  period  of  time  where  you  nave  a  degraded 
operational  capability. 


*  *  *** 
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Manager  #9. 


Well,  the  biggest  ones  [headaches]  are  the  unknowns  of  what 
happens  when  you've  got  production  airplanes  being  built  and 
you  still  have  the  test  program  going  on  determining  design 
changes — potential  design  changes. 


Manager  #11. 


***** 


Concurrency  to  me,  is  bad  because  you're  going  to  uncover 
things  during  flight  test  that  have  to  be  corrected,  and 
you're  going  to  have  to  retrofit  whatever  you've  got  on  the 
line  already  with  those  changes. 

So  when  you're  talking  about  the  risks  of  concurrency,  of 
evolving  the  flight  test  changes  that  need  to  be  made  to  the 
airplane,  the  more  schedule  compression  you  have,  another 
big  chunk  of  dollars  is  probably  involved  in  the  risk  of 
having  to  change  drawings  and  all  the  tech  data. 

***** 

Manager  #12. 

I  chink  one  of  the  biggest  problems  is  the  managing  of  the 
funds  mainly  because  you  have  to  get  more  retrofit  funds  in. 

***** 

Manager  #13. 

Well,  the  headaches  occur  because  you  try  to  do  it  too  fast. 
That  is,  you  miss  things.  And  that's  really  where  the  risk 
is — you  always  have  the  problem  of  deploying  it  and  put  a 
lot  of  additional  work  load  on  people  in  the  field.  On  the 
maintenance  people,  having  to  work  with  tech  orders  that 
maybe  aren't  quite  right.  On  support  equipment  that  maybe 
it  should  have  been  designed  a  little  bit  better. 

***** 

Manager  #14. 

And  if  you've  got  invention,  it's  just  dumb  to  try  to  run  a 
concurrent  program — because  you  just  can't  keep  up  with  it. 

Tne  bureaucracy  is  designed  for  non-concurrent  programs. 

And  so,  we've  got  thousands  of  people  above  us — staff — that 
cannot  think  outside  of  the  bureaucracy.  And  since  it  won't 
fit,  they  get  upset  and  unstable.  We've  had  all  kinds  of 
problems . 


Manager  #15. 


Well,  you  nave  to  interrupt  a  production  program,  not 
interrupt,  but  when  you're  doing  production  while  still  in 
development,  it  provides  interruptions  in  an  orderly 
process.  And  these  interruptions,  sometimes,  create 
unforeseen  problems--things  you  can't  plan  on.  These 
problems  generate  some  chaos  in  the  program,  or  instability, 
which  lend  to  schedule  or  cost  impact. 

Concurrency,  because  it  does  generate  a  challenge  within  a 
snort  time  span,  can  mean  that  you  have,  perhaps  an 
optimistic  schedule.  And  if  you  build  your  forecasts  or 
obligations  on  an  optimistic  schedule,  then  as  things  slip, 
and  they  can  in  a  concurrent  program,  then  for  the  financial 
people,  it  poses  a  problem  in  explaining  deviations  in 
obligations — actual  versus  forecast.  In  today's 
environment,  obligation  deviations  or  unobligated  balances 
are  perceived  to  be  problems.  And  Congress  and  the  Office 
of  the  Secretary  of  Defense  say  that  if  you  can't  obligate 
it,  you  don't  need  it.  And  if  you  don't  need  it,  then 
they'll  take  it — and  they  are. 

***** 

Manager  #16. 

Many,  many.  And  the  biggest  headache  that  I  see  as  I  told 
you  before,  is,  you  have  to  make  decisions  without  all  the 
information  that  you'd  like  to  have. 

So  concurrency  brings  on  a  lot  of  crisis  management;  as 
opposed  to  well  thought  out,  "here's  the  schedule,  and  let's 
go  out  and  do  it." 


***** 

Manager  #17. 

Well,  there's  a  lot  of  work  involved  in  administering  and 
accomplishing  the  retrofits  that's  required  since  you're 
pressed  into  production  maybe  before  you've  had  all  your 
testing.  And  you  can  discover  problems  that  you  need  to  fix 
and  that  require  retrofit.  That's,  I  don't  know  whether  you 
measure  it  all  in  cost  or  not.  There's  just  a  lot  of  labor 
and  that  l kind  of  thing]  involved.  You  measure  that  one  in 
a  loc  of  ways  other  than  cost. 

it  it  it  it  it 

Manager  #18. 

First  off,  I  tnink  we  tie  into  a  design  during  the 
development  stage  that,  because  of  the  concurrency  and  the 
need  to  switch  in  and  get  ready  and  start  production  so 


quickly#  you  aren't  as  flexible  in  your  design.  When  you 
see  problems  with  it#  you  only  have  time  to  patch  it — you 
don't  have  time  to  redesign,  if  necessary,  to  rethink  your 
approach  or  anything  like  that. 

The  second  part  of  it  is#  that  you  don't  baseline  your 
configuration  early  enough  for  production  and  you’re  forced 
to  go  into  production,  at  least  the  first  one  or  two  lots  of 
production#  without  a  qualified  frozen  configuration.  You 
probably  haven't  gotten  to  FCA/PCA  [Functional  Configuration 
Audit/Physical  Configuration  Audit],  even  before  you  go  into 
production.  So  what  you're  doing,  is  buying  off  on  a  lot  of 
potential  Class  I  changes,  once  you  get  into  production. 
Because  you' re  doing  testing  and  qualification  at  the  same 
time  you've  already  gone  on  production. 

I  think  one  other  negative  that  no  one  really  thinks  about 
is,  I  think,  it  puts  a  lot  of  added  pressure  on  the  human 
resources  that  you're  using,  both  government  and  contractor. 
And  nobody  really  visualizes  the  cost  that  is.  But  I  think 
we're  burning  out  and  using  a  lot  of  extra  resources  than  we 
would  if  we  did  it  in  a  normal  flow  of  time. 

By  definition,  since  you  have  concurrency,  and  particularly 
a  lot  of  concurrency,  you're  not  going  to  have  a  whole  lot 
of  that  nice  neat  data  to  show  whether  he's  ready  for 
production.  You've  bought  off  on  the  fact  that  you're  not 
going  to  have  all  that  data.  So  really,  what  you're  looking 
at  in  that  circumstance  is  more  along  the  lines,  "are  there 
any  significant  problems  there  that  would  say  the  contractor 
shouldn't  continue  with  production  or  proceed  with 
production?"  As  opposed  to,  "is  he  ready?" 

***** 

Manager  #19. 

Well,  I  think  you  really  get  less  performance.  And  I'm  not 
talking  about  the  airplane  performance.  I'm  talking  about 
total  performance  of  the  contractor  because  you  start 
compromising.  You  eventually  realize  you  can't  get  to  where 
you're  going,  so  therefore,  if  it  was  non-concurrent,  you 
would  have  made  those  design  changes  where  now  you  can't 
afford  to.  Not  from  a  dollar  standpoint,  but  for  a  going-on 
with  the  program. 


Manager  #20. 

In  general,  the  concurrency  will,  from  what  I've  seen  in  the 
past,  is  that,  yes,  we’re  able  to  put  something  out  in  the 
field,  but  then  we  end  up  doing  a  lot  of  catch  modification 
to  take  care  of  deficiencies  and  things  like  that. 


...concurrency  requires,  has  driven  the  management,  the 
micro-management,  at  ail  levels  to  the  point  that  you  spend 
tremendous  amounts  of  time  reporting  on  those,  on  your 
concurrent  activities,  to  the  detriment  of  just  program 
overview — of  being  able  to  put  your  time  where  you  need  to 
put  it. 


Appendix  D:  Measurement  Question  Four 
Note:  The  following  paragraphs  are  quotations  from 
interview  transcripts  unless  material  is  bracketed. 


How  Can  the  Additional  Risk  of  Concurrent  Acquisition  Be 
Reduced? 

Manager  #1 . 

Well,  you'd  certainly  need  a  lot  more  manpower  in  the  SPO  to 
manage  a  concurrent  program.  And  I  think  the  SPO  needs  a 
good  deal  more  in  terms  of  automated  data  from  the 
contractor  in  order  to  proceed  expeditiously.  Probably  need 
a  lot  more  management  reserve  to  be  able  to  have  money  for 
ECPs  [Engineering  Change  Proposals]  and  things  like  that,  to 
fix  problems  tnat  come  up  because  of  the  rush  to  complete 
design . 

***** 

Manager  #2. 

We  can't  go  into  it  blind — and  that's  a  prerequisite.  We've 
structured  the  program  on  demonstration  milestones,  so  we 
have  certain  milestones  that  need  to  be  completed  to  enter 
the  next  phase.  One  of  the  demonstration  milestone  criteria 
for  entering  production,  the  low  rate  initial  production,  is 
the  completion  of  the  first  third,  roughly,  of  the  flight 
test  program. 

If  you're  going  to  have  concurrency,  you  have  to  put  more 
rigor  into  the  first  flight  tests.  We're  jumping  in  fairly 
heavy  in  terms  of  test  objectives  and  taxing  the 
capabilities  of  the  - . 


So,  if  you're  going  to  go  concurrent  like  this,  the  classic 
DT&E  [Developmental  Test  &  Evaluation],  followed  by 
DT&E/IOT&E  [Initial  Operational  Test  &  Evaluation],  followed 
oy  OT&E  [Operational  Test  &  Evaluation],  become  rather 
blurred.  We  have  to  achieve  some  OT&E  objectives  right  from 
Day  One.  So  the  first  flight  is,  you've  got  OT&E  objectives 
as  well  as  DT&E  objectives  in  it.  You  can't  have 
concurrency  if  you  don't  do  it  that  way. 


They  have  to,  if  you're  going  to  make  a  production  decision 
based  on  the  results  of  very  limited  testing,  the  vehicles 
have  to  be  really  representative,  or  as  close  as  you  can 
make  them  to  the  final  configuration. 
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We're  going  to  baseline  the  program. 

We  believe  they'll  [future  configuration  changes]  be  minor 
sorts  of  things  that  can  be  done  in  block  update  and  they 
could,  in  fact,  be  pushed  way  out  until  you've  fielded  the 
entire  fleet  and  you  cycle  them  back  through  for  a  retrofit, 
or  retrofit  in  the  field  or  something  of  that  sort. 

***** 

Manager  #3. 

Well,  it  helps  to  have  high  level  concern  like  we  did.  We 
were  able  to  do  things  because  we  had  SECDEF's  [the  Office 
of  the  Secretary  of  Defense]  interest. 

You  need  a  good  relationship  with  your  contractor — because 
you're  going  to  ask  him  to  do  things  he  might  not  normally 
do,  or  you  wouldn't  normally  ask  him  to  do  on  a  standard 
program. 

I  can  see  that  in  the  way  we  do  business,  we,  just  in  the 
length  of  the  contracting  cycle,  that  it  takes  six  to  nine 
months,  or  a  year,  to  actually  buy  something — not  to  buy — to 
get  it  on  contract;  from  the  time  you  decide  you  want  it  to 
the  time  you  sign  a  contractor.  And  you  spend  a  lot  of  time 
reporting.  We  build  in  a  lot  of  time  and  a  lot  of  work  into 
the  system  that  makes  things  longer. 

If  you're  concurrent,  you're  in  a  rush  to  do  something.  And 
if  you're  in  a  rush,  you  don't  always  have  the  time  to  wait 
six  months  or  nine  months  to  get  a  contractual  action  out 
before  the  contractor  turns  something  on.  We  did  a  lot  of 
things  with  phone  calls  and  letters  that  we  should  have  done 
with  contracting  actions,  and  we  had  the  cooperation  from 
the  contractor  we  needed. 

The  tester  is  also  going  to  find  a  lot  of  things  wrong,  that 
he  might  not  find  wrong  if  the  things  were  properly  tested 
and  fixed  and  tested  again.  So  you  need  understanding  from 
him . 

From  the  headquarters,  you  need  understanding  of  wnat 
concurrency  means,  and  that  it's  going  to  cost  more  down  the 
road — and  it's  hard  getting  that  understanding  now.  They 
remember  when  they  were  pushing  us  to  make  the  IOC,  and  now 
that  we  need  to  fix  a  lot  of  the  equipment,  and  that  it's 
not  as  reliable  as  they  would  like  it  to  be,  they  don't 
remember  tnat  as  well  anymore. 


Manager  #4 


Well,  if  we're  smart,  we  won't  go  into  full  scale 
development  on  anything  that's  real  high  risk.  But 
certainly,  if  it's  a  real  risk  item  technically,  then  that 
would  blow  concurrency  out.  I  would  think  that  we're  smart 
enough  now,  after  all  these  years,  that  we  would  not  go  into 
FSD  with  a  large,  large  risk. 

***** 

Manager  #5. 

If  I  were  doing  it,  I  would  probably  load  more  people  into 
the  development  period  and  shorten  that,  and  then  still  do 
it  sequentially.  I  would  have  a  hard  time  saying,  "do  it 
concurrently."  Probably  because  I've  had  to  live  with  the 
people  who  had  to  live  with  the  problems  that  concurrency 
caused . 


Manager  #6. 


*  *  *** 


I  would  like  to  have  streamlined  management  procedures.  I 
wouldn't  want  to  be  tied  down  by  all  of  the  reporting 
systems  and  administrative  things  they  get  tied  down  by. 
Because,  to  me,  a  concurrent  program  is  a  much  more  active 
program.  There  are  so  many  things  going  on  at  the  same 
time.  So,  you  know,  you  need  not  to  be  bogged  down  in 
administrative  type  things.  You  need  to  have  the  people, 
and  that's  always  a  constraint,  and  that's  a  constraint 
nowadays.  Those  two  things,  for  sure.  Those  are  things  you 
need  to  do  any  program  well,  but  I  think  for  a  concurrent 
program  they're  even  more  vital. 


***** 

Manager  #7. 

I  don't  think  it's  a  good  thing  thing  to  apply  to  programs 
that  do  have  high  technical  risk,  because  in  that  case,  I 
think  you  do  end  up  spending  a  lot  more  money  for  that. 

tfe  tend  to  be  so  success-oriented  on  programs  that  we're 
willing  to  do  concurrently,  that  we  under-plan  the  resources 
needed  to  do  them.  Particularly  in  terms  of  things  like 
test  articles.  You  know,  we  tend  to  buy  too  few  because  we 
don't  think  we're  going  to  have  problems  with  them.  And  we 
will  uncover  some  problems ....  But  the  design  itself  typi¬ 
cally  does  have  to  be  changed  and  we  tend  to  be  overall, 
success-oriented,  and  not  plan  for  enough  test  time  and  test 
articles . 


Manager  #8. 


So  if  you' re  going  to  work  it  concurrent,  if  you  have  a 

concurrent  program — especially  like  the  - ,  which  was 

highly  concurrent,  you  can't  let  problems  fester.  As  soon 
as  you  spot  them,  you  have  to  go  out  and  solve  them.  So  you 
need  good  people  and  experienced  people.  That  makes  a  big 
difference . 

[This  manager  also  stated  that  it  is  narder  to  compress 
systems  that  "push"  the  state-of-art . ] 

★  *  *  *  * 

Manager  #11. 

Well,  I  think  that  the  lesson  I've  seen,  is  you  need  to  pay 
a  lot  of  attention  to  making  the  contractor  do  the  necessary 
development  work  quick  enough.  Because  there's  no  catching 
up  down  the  road.  And  the  more  you  have  of  concurrency,  the 
more  crucial  that  is. 

...if  I  had  to  make  one  single  recommendation  from  my 
experience  at  the  working  reviews,  to  relieve  the  risk  of 
concurrency,  it  would  be  to  have  a  cost-plus  contract.  And 
that  flies  in  the  face  of  the  current  philosophy  of 
contracts. 


***** 

Manager  #12 

We  don't  do  our  [support]  planning  properly  in  order  to  look 
at  a  concurrent  program  and  work  it. 


v>. 


***** 


Manager  #13. 


If  you  have  to  build  a  program  with  concurrency  in  it,  you 
have  to  plan  for  it  and  budget  additional  PCO  money,  as  we 
call  it,  to  cover  these  changes. 


The  problem  with  concurrency  is  that  you  can  get  programs 
too  concurrent.  It's  like  everything,  too  much  of  something 
is  awfully  bad,  too  little  of  it  is  also  bad  because  it 
drags  the  program  out  so  far.  So  you  have  to  balance 
concurrency  vith  risk.  And  each  program  is  going  to  have  a 
different  amount  of  risk  associated  with  it.  You  almost 
have  to  make  a  concurrent  decision  on  a  program  by  program 
basis . 
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I  don't  think  you  would  try  to  take  a  [concurrent]  program 
into  FSO  without  the  concept  definition  work  up  front.  You 
see,  that's  where  your  real  risk  is  going  to  be. 

*  *  *  *  * 

Manager  #14. 

One,  you  can't  have  any  invention.  Whatever  you're  going  to 
put  into  the  program  has  to  be  [already]  invented. 

The  other  thing  is  that  you  need  to  fix  the  baseline.  When 
I  say  fix  the  baseline,  you  decide  what  you're  going  to 
build  in  terms  of  requirements  and  you  don't  ever  change 
them.  And  you've  got  to  have  enough  discipline  in  the 
organization;  and  when  I  say  discipline,  that's  discipline 
from  DoD  on  down  to  through  the  SPOs,  that  we're  not  going 
to  change  anything. 

The  other  thing  is,  if  you're  going  to  have  a  concurrent 
program,  you're  going  to  have  minimum  invention,  then  you 
ought  to  get  most  of  your  [money]  authorized  by  Congress 
[for  multi-year  funding]. 

And  all  of  that  has  to  be,  it  just  take  experience.  You 
know,  if  you've  got  a  lot  of  experienced  people,  then... The 
other  thing  you've  got  to  rely  on,  is  you've  got  to  rely  on 
your  engineers. 

What  you  ought  to  do  is  what  makes  common  sense.  And  if  it 
makes  common  sense  to  go  down  to  these  vendors,  you  can 
convince  the  primes  and  stuff  that  it  makes  common  sense. 

And  we  have  never,  on  all  the  programs  I've  worked  on,  we 
[never  failed  to]  work  down  to  the  lowest  component 
suppliers . 

The  other  things  you've  got  to  do  on  any  program  is  you've 
gotta  work  as  a  team.  You  can't  have  a  we-they  attitude. 

You  know,  the  Air  Force  produces  nothing.  We  build 
absolutely  nothing.  We  don't  do  a  damn  thing.  Our  whole 
industry  supports  us.  And  if  you  reach  a  point  where  you're 
in  an  adversarial  role  with  your  contractor,  you  lose — just 
automatically,  you're  going  to  lose. 

The  other  thing  that's  very  important  in  any  program  is  that 
you're  honest  on  your  funding  requirement.  And  when  I  say 
honest,  you  shouldn't  be  in  a  position  of  trying  to  make  a 
judgment. .. .But  all  too  often,  the  Program  Manager  becomes 
emotionally  involved  in  these  programs,  and  his  people  too, 
and  they  say,  "on,  we  can  make  it  by."  You're  never  going 
to  do  that. 


Manager  #16. 

So  personally,  from  what  I've  seen  and  the  headaches  I've 
had,  I'd  say  stretch  it  out  a  little  bit. 

***** 

Manager  #17. 

I'd  want  the  system  to  be  somewhat  flexible,  I  guess  to 
accommodate  the  changes  that  testing  might  discover.  I'm 
thinking  of  things  like  a  lot  of  spare  memory  capacity  in  a 
computer.  I  would  probably  tend  to  shy  away  from  major 
leaps  in  technology  in  the  development  phase. 

I  would  like  some  experienced  people  that  have  lived  through 
a  retrofit  phase  of  production. 

***** 

Manager  #18. 

I  think  one  big  factor  would  be  a  program  that  does  not 
require  an  advancement  in  technology. 

The  second  part  would  be  to  go  ahead  and  develop  a  program 
schedule  that  would  have  a  lot  of  upfront  testing  and  qual 
testing.  And  we,  the  government,  would  have  to  accept  a  lot 
of  the  risk  in  early  production  toward  Class  I  changes. 

I  don't  like  fixed  price  contracts  for  concurrency. 

Well,  first  off,  is  just  the  environment — the  political  and 
psychological  environment.  You're  supposed  to  not  make 
mistakes.  You're  supposed  to  be  failure  free.  There's  a 
fear  of  failure,  I  think,  right  now  to  a  certain  extent. 

Yet  with  concurrency,  you're  almost  guaranteed,  because  it's 
in  development,  that  you're  going  to  have  problems  and 
you're  going  to  have  mistakes. 

***** 

Manager  #19. 

So  what  we  should  have  done,  if  you're  going  to  have 
concurrency,  you've  got  to  have  a  tighter  SOW  [Statement  of 
Worx] .  You've  got  to  tie,  if  you  have  these  things 
[extensive  ground  testing],  in  your  contract  and  SOW,  to 
reduce  the  risk  of  concurrency,  you've  got  to  tie  them  down 
to  an  event,  which  I  would  think  is  the  CDR  [Critical  Design 
Review],  You  might  even  want  to  tie  them  down  to  a  PDR 
[Preliminary  Design  Review], 


[This  manager  also  stated  that  a  fixed  price  contract  was 

desirable  for  a  concurrent  program. ] 

***** 

Manager  #20. 

A  low  technical  risk  is  obviously  the  first  thing  that  you 
want  to  do.  Because  chat's  going  to  reduce  the  potential 
problems  that  you  can  have  with  technology  and  design  and 
the  design  changes. 

The  second  thing  with  concurrency  is,  being  able  to  provide 
sufficient  test  resources,  early  on  in  the  program,  to  allow 
for  testing  to  be  accomplished  efficiently  in  the  time  frame 
that  I  have . 


Appendix  E:  Measurement  Question  Five 
Note:  The  following  paragraphs  are  quotations  from 
interview  transcripts  unless  material  is  bracketed. 


How  Do  Contractors  Feel  about  tne  Use  of  Concurrency? 
Manager  #1 . 

...the  contractors  are  good  soldiers,  they  do  what  we  tell 
them  to  do. 


Manager  #4. 

Well,  I  think  tnat  our  contractor's  pretty  positive  on 
it... on  the  amount  of  concurrency  that  we're  doing  [which  he 
described  as  centering  primarily  on  the  support  equipment] . 


Manager  #8. 

I  think  you'd  find  very  positive  feelings  on  the  -  about 

how  the  program's  been  run.  I  think  they'd  recognize  that 
that  was  the  way  that  program  had  to  be  run  to  get  the 
aircraft  out  there  as  soon  as  possible. 


Manager  #9. 

Some  contractors  would  like  to  be  more  concurrent.  There 
have  been  some  proposals  that  during  the  process  of  our 
concept  development  said,  "let's  release  our  production 
while  we're  building  the  flight  test  vehicles.  And  let's 
make  it  literally  a  commercial  practice  system  kind." 


Manager  #10. 

I  guess  it  would  depend  on  what  kind  of  contract  you  had 
with  them. 


Manager  #11. 

Well,  if  you  pay  them,  I  don't  think  they  care.  When  they 
build  their  programs  and  bring  them  up  to  me,  if  tney  have 


any  brains  at  all,  they’re  going  to  build  in  the  price  for 
that  risk. 


***** 

Manager  #13. 

The  contractors,  on  our  program,  tend  to  want  us  to  go 
faster  with  the  program  as  opposed  to  slower. 

***** 

Manager  #14. 


It  didn't  bother  them  at  all.  They  thought  it  was  great. 
And  they  were  enthusiastic  about  it. 


Manager  #15. 


*  *  *** 


If  you  had  a  concurrent  program  that  had  a  low  technical 
risk,  I  don't  think  a  contractor  would  mind. 

***** 

Manager  #16. 

Nobody  likes  it.  Nobody  likes  it  at  all.  But  they  signed 
up  to  a  contract  which  had  an  accelerated  schedule. 

***** 

Manager  #17. 


I  guess,  on  balance,  they  would  probably  welcome  the  earlier 
commitment  to  production.  Because  once  the  system's  in 
production,  it's  more  of  a  sure  thing.  As  long  as  it's  in 
development,  not  yet  in  production,  they're  faced  with 
greater  uncertainty  about  what  the  real  magnitude  of  the 
program  is  going  to  be. 


*  *  *** 
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Appendix  F:  Measurement  Question  Six 
Note:  The  following  paragraphs  are  quotations  from 

interview  transcripts  unless  material  is  bracketed. 


How  Do  the  Using  Commands  Feel  About  the  Use  _of  Concurrency? 
Manager  #1 


The  end  user  is  not  a  very  disciplined  or  well  behaved  actor 
in  this  play.  They  would  tend  to  be  very  vague  about  their 
requirements  in  the  first  place,  and  then  when  they  want  it 
fast,  will  accept  almost  anything.  So  they  tend  to  switch 
on  you  midstream. 


★  ★  *  *  * 


Manager  #2. 


They  could  care  less  how  we  do  it.... I  don't  have  any 
quarrel  with  their  focusing  [on  the]  the  operational  utility 
and  the  IOC — that  should  be  what  their  focus  is. 


***** 


Manager  #3. 


...they  want  it  as  soon  as  they  get  it,  and  then,  as  soon  as 
they  get  it,  they  start  complaining  about  it.  I  think  they 
like  concurrency  until  they  get  it,  and  then  after  they  get, 
they  don't  like  it  anymore. 


***** 


Manager  #4. 


Well,  I'm  not  so  sure  they  know  what  it's  all  about, 
frankly . 

It  It  *  *  * 

Manager  #5. 

Tney  aren't  happy.... you  have  problems  and  those  schedules 
start  slipping,  the  user  becomes  upset  because  he  missed  his 
schedule  in  the  first  place,  and  then  becomes  upset  again, 
whan  he  sees  you  using  his  system,  his  production  system,  to 
work  out  bugs.  And  he  hatas  being  the  guinea  pig,  so  to 
speak . 

***** 
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Manager  #6 


So  the  user  always  wants  the  thing  as  fast  as  they  can  get 
it . 

I  think  their  griping  is  in  direct  proportion  to  how  good  a 
system  you  give  them.  You  know,  people  tend  to  forget  what 
you  had  to  go  through  to  get  something.  And  if  it's  good, 
fine.  If  it's  not,  then  they  really  don't  care  how  it  got 
there,  they  still  want  a  good  system.  Because  it's  their 
lives  that  are  on  the  line  when  you  give  them  something 
that's  not  working. 


Manager  #7. 


***** 


...I  think  you'll  find  that  the  user  understands  we're  going 
concurrency,  and  he's  really  for  it.  As  the  program 
proceeds  and  we  begin  to  encounter  difficulties,  which  as  I 
said  before  is  almost  inevitable,  then  I  think  the  attitude 
of  the  user  changes  to  where,  "well,  we'll  share  the  risk 
with  you."  And  then,  eventually  the  thing  gets  into  the 
field,  and  if  it  doesn't  live  up  to  its  expectations,  he 
tends  to  jump  on  the  developer  for  having  signed  up  to  that. 
And  that's  not  unreasonable,  because  ultimately  we  did  sign 
up  to  it,  or  we  wouldn't  have  done  it  that  way. 


***** 

Manager  #8. 

I  think  they're  happy.  You  know,  they'd  like  to  get  a 
perfect  aircraft,  the  first  one  down  there.  But  that 
doesn't  happen,  because  it  slows  everything  down. 


***** 

Manager  #9. 

The  user  is  very  reluctant  to  say,  on  the  basis  of  three  or 
four  flights,  for  instance,  "yeah,  this  airplane  does  what 
we  want  it  to  do  and  we  can  really  use  it  for  wnat  we  want" , 
and  then  getting  locked  into  a  design  that  we  find  out  later 
on,  will  cost  him  millions  of  dollars  to  fix,  yet  it's 
deficient  for  doing  what  they  need  to  do.  So  they  view  the 
concurrency  thing  as  tying  their  hands  a  bit  more. 

***** 

Manager  #10. 

...they  know  they  have  a  threat  to  meet,  and  they're  looking 
for  a  weapons  system  that  will  meet  that  threat.  I  don't 


think  they  want  an  airframe  out  there  with  just  an  airframe, 
no  avionics,  no  armament  type  thing. 


***** 

Manager  #11. 

They  lay  out  the  requirements,  design  the  requirements  and 
tnis  is  the  time  they  want  it,  you  know;  that  they  want  more 
goodies,  more  requirements,  and  don't  make  it  take  longer, 
and  don't  tell  me  that  it's  going  to  cost  money. 

*  *  *** 

Manager  #12. 

The  user  hates  concurrency. 

The  user  doesn't  like  concurrency,  because  concurrency 
always  ends  up  that  he  doesn't  have  what  he  needs  when  he 
needs  it. 

But  they  [the  using  commands]  don't  like  concurrency — they 
don't  like  the  results  of  concurrency  and  the  way  we  do  it. 

***** 

Manager  #13. 

You  get  it  from  the  general  officer  level,  or  initially  in 
the  program,  at  the  planning  level,  to  get  it  done  quickly. 
And  yet,  when  you  try  to  deploy  it  and  after  having  done  it 
quickly,  you  get  all  kinds  of  grief  from  the  people  who  are 
having  to  do  the  job. 

***** 

Manager  #14. 

So  they  usually  go  catatonic  [when  faced  with  a  highly 
concurrent  program] . 

***** 

Manager  #15. 

I  think  the  user,  the  user  works  with  us.  And  when  they 
receive  the  airplane,  they  want  to  understand  it  and  be  able 
to  apply  it.  I  think  that  a  program  with  a  short  time  span, 
that's  concurrent,  poses  tne  same  problems  for  the  user  as 
it  does  for  the  developing  command.  And  also  for  the 
Logistics  Command  as  well — the  maintainer  has  the  same 
problem . 
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Manager  #16. 
Cpt  Foote.  I 


Manager . 


What  was  their  [the  users']  feeling  when  you 
suddenly  started  to  run  into,  really  from  many 
other  interviews,  the  normal  type  of  things 
that  you  would  expect  from  a  highly  concurrent 
program? 

They  told  me  to  fix  it — and  make  sure  that  they 
get  effective,  reliable  hardware  out  there  when 
we  made  deliveries. 


Cpt  Foote.  While  still  meeting  the  original  schedule? 
Manager.  The  end  [date]  has  never  changed. 

***** 

Manager  #17. 

They  always  want  the  system  right  now — most  of  them.  So 
they  probably  tend  to  support  concurrency  because  they  think 
it's  going  to  get  them  capability  in  the  field  sooner — and 
it  will. 


***** 


Manager  #18. 


...I  think  they'll  usually  come  up  with  requirements  (they, 
the  user),  that  can  be  backed  off  of.... So  they're  building 
in  more  concurrency  in  order  to  take  care  of  a  slipped  IOC. 


Manager  #19. 

...you  build  up  a  lot  of  unnecessary  animosity  from  the 
user  command ... .They ' ve  gotten  to  not  like  it  after  they 
get  into  it  because  it  restricts  their  reviews.  They  get 
involved  too  late  because  the  airplanes  are  almost 
delivered  to  them  before  they've  had  a  chance  to  look  at 
the  prototypes,  and  they  feel  uncomfortable — ours 
definitely  does. 


Manager  #20. 

...the  user  talks  out  of  both  sides  of  his  mouth. ... It ' s 
very  difficult.  You  can't  satisfy  them  either  way. 
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Appendix  G:  Measurement  Question  Seven 
Note:  The  following  paragraphs  are  quotations  from 

interview  transcripts  unless  material  is  bracketed. 


Should  Inter im  Contractor  Support  be  Employed  on  a 
Concurrent  Program? 

Manager  #4. 

Now,  you  might  even  consider,  during  that  low  rate 
[production],  that  logistics  of  the  whole  damn  thing  be 
supported  by  the  contractor.  Spare  parts  and  everything — 
and  it's  not  a  bad  thought. 


***** 


Manager  #8. 


To  be  honest  with  you,  I  think  we  overrate  this  in-house 
support.  In  quest  of  that  goal,  I  think  we  sometimes  spend 
money  unwisely.  It's  often  cheaper  to  get  the  contractor  to 
do  it  until  the  system  flattens  out. 


*  *  *** 


Manager  #9. 


Well,  I  think  that  we've  had  an  awful  lot  of  programs  that 
were  put  together  based  upon,  as  you  said,  full  up  plue  suit 
support  from  the  organizational  level  on  up.  That  was  an 
ideal  that  nobody  ever  seriously  considered.  More  recently, 
we  have  actually  recognized  the  situation  and  provided  for 
ICS  [Interim  Contractor  Support]  as  a  built-in  option  into 
the  contracts  and  have  been  attempting  to  incentivize  the 
contract  which  will  get  the  Air  Force  operational  blue  suit 
(organic)  capability  as  soon  as  possible. 


***** 


Manager  #10. 


They  [the  contractor]  have  the  capability,  which  they  have 
to  build  up  anyhow,  they  have  the  capability — we  just  buy 
that  for  a  little  bit  longer.  I  think  it's  very  important 
that  we  have  the  option  to  use  that  if  we  need  to. 


Manager  #12 


...I  am  a  hard,  firm  believer  in  ICS.  Plan  it,  do  it,  and 
do  it  right,  and  you'll  support  a  system  better.... we  refuse 
to,  we  in  tne  support  side  of  the  house,  I  say,  do  not  sit 
down  and  say,  "with  a  concurrent  program,  we'll  plan  for  it 
and  plan  smart."  Instead  they  plan  for  an  organic 
capability  and  then  don't  get  it. 


Manager  #13. 


***** 


We're  doing  that — you  nave  to  do  that. 


Manager  #15. 


*  *  *  *  * 


I  think,  usually  for  a  concurrent  program,  that  ICS  is 
necessary.  You  have  to  have  a  contractor  support  the 
airplane  until  you  can  get  organic  capability. 


***** 
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Note:  The  following  paragraphs  are  quotations  from 

interview  transcripts  unless  material  is  bracketed. 


What  Are  the  Managers1  Overall  Appraisals  of  Concurrency? 
Manager  #1 . 

The  cycle  in  buying  a  weapon  system  is  so  long,  that  you're 
almost  forced  into  concurrency  of  some  sort. 

***** 

Manager  #2. 

Well,  I  think  that  concurrency  has  gotten  a  bad  rap.  In 
this  business,  you've  got  to  have  some  concurrency.  If 
you're  going  to  have  a  program  that  you  want  to  get  out  in  a 
reasonable  length  of  time,  you're  going  to  have  to  have  some 
concurrency ... .A  lot  of  less  experienced  Program  Managers,  I 
think,  tend  to  focus  on  trying  to  take  concurrency  totally 
out  of  programs,  and  I  think  it’s  the  wrong  focus.  I 
certainly  counsel  all  of  my  young  project  managers  tnat  what 
they  ought  to  try  to  do  is  nit  upon  the  right  amount  of 
concurrency,  hence,  the  right  amount  of  risk  for  that 
particular  project  or  program  that  you're  working  on.  But 
we  shouldn't  be  afraid  of  putting  concurrency  and  the 
attendant  risk  into  a  prograin.  I  think  that's  the  nature  of 
our  business. 

*  ★  *  ★  ★ 

Manger  #3. 

If  we  had  to  do  this  program  again,  we  would  have  no  choice, 
but  it's  better  not  to  be  concurrent  or  to  have  the  minimal 
amount  of  concurrency  as  you're  able  to,  as  long  as  you  can 
do  that  and  still  meet  your  objectives. 

***** 

Manager  #4. 

I  guess  I'm  generally  in  favor  of  concurrency,  because  I 
think  it  does  get  systems  out  in  the  field  sooner.  And  I 
think  it  takes  too  long  right  now  for  us  to  get  systems  out 
in  the  field.  And  I  think  that,  like  I've  always  said,  that 
we  need  to  be  slow  about  the  quantities  we're  getting  in  the 
field  and  limit  the  initial  deployment.  Because  I  think 
that  what  we  really  need  to  do  a  better  job  of,  is  get 


K‘ 


feedback  from  the  initial  deployment  in  the  field,  rather 
than  fill  up  the  whole  world  with  systems. 


Manager  #5. 


*  *  *** 


...if  it  didn't  come  out  clear  enough,  I  don't  really  think 
it's  good  [concurrency].  I'm  one  of  the  advocates  that  it 
l system  acquisition]  should  be  done  sequential. 


***** 

Manager  #6. 

If  you  want  to  get  something  in  the  system  fast  and  you 
don't  have  the  time  to  take  the  normal  eight  to  ten  to 
twelve  years,  you're  almost  forced  to  do  that  [concurrency]. 

***** 

Manager  #7. 

I  think  if  the  need  is  great  enough,  if  the  user's 
requirements  dictate  that  you  go  concurrency,  I  don't  think 
it  ought  to  be  looked  upon  as  a  horribly  bad  thing. 
Particularly  if  you  don't  challenge  the  technology,  which  I 
think,  gets  you  into  big  money  and  doing  it  again  type  of 
thing.  But  if  the  technology  is  well  in  hand,  and  you're 
willing  to  accept  the  setbacks  that  you're  inevitably  going 
to  have,  I  think  you  still  get  there  quicker  and  probaoly, 
at  less  cost  than  the  other  way.  I  think  it  makes  sense. 

***** 

Manager  #8. 

You  have  to  accept  a  certain  amount  of  risk.  If  you  don't 
have  some  concurrency,  I  don't  think  you'll  ever  get  a 
program  fielded.  If  you  solved  all  the  problems  before  you 
went  into  production,  you'd  never  get  into  production — 
because  there  are  always  going  to  be  problems. 

***** 

Manager  #9. 


It's  almost  the  only  way  to  maintain  any  kind  of  realistic 
schedule  in  terms  of  deliveries. 


***** 


Manager  #10. 


You  have  to  look  at  the  situation,  you  look  at  the  threats, 
you  look  at  the  technologies,  you  look  at  the  funding 
available  (that's  another  problem),  and  you  make  the  best 
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decision  at  that  time 
all  for  it. 


If  concurrency  is  required,  then  I'm 


★  *  ★  *  * 

Manager  #11. 

...there's  no  way  you  can  avoid  not  having  some  level  of 
concurrency.  Because  if  you  try  to  avoid  all  concurrency, 
then  you  never  would  get  it  done. 

***** 

Manager  #12. 

I  know  of  very  few  non-concurrent  programs.  And  it  just 
depends  on  your  degree  of  concurrency  whether  you've  got 
problems  or  not. 


*  it  ★  *  ★ 

Manager  #13. 


I  would  say  that  concurrency  should  not  be  colored  bad — just 
because  of  the  name  concurrency.  That  each  program  needs  to 
be  looked  at  on  a  case  by  case  basis.  And  you  need  to  make 
a  judgment  or  decision  on  how  much  concurrency  is 
reasonable.  You  weigh  off  the  risks  with  the  schedule. 


*  *  *  *  * 

Manager  #14. 


Any  time  you've  got  economic  escalation,  and  I'd  say 
anything  over  2%  per  year,  you  ought  to  go  concurrency 
[assuming  little  or  no  "invention"]. 


Manager  #15. 


★  *  *  *  ★ 


In  fact,  concurrency  in  a  low  risk  program,  a  low  technical 
risk  program,  probably  makes  sense.  You  don't  need  to  drag 
out  that  program.  Concurrency  with  a  high  technical  risk 
program  becomes  a  real  challenge.  Not  only  to  the 
contractor,  but  the  Program  Manager. 

★  *  *  ★  it 

Manager  #16. 

I  don't  want  to  do  it  again.  That  is,  it's  been  a  headache. 
I've  had  to  drive  my  people  and  I've  had  to  drive  myself  in 
order  to  accomplish  this  end  goal. 


*  *  *  *  * 
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Manager  #17. 

Well,  it's  challenging,  but  it's  probably  the  best  way  to 
get  new  capabilities  in  the  field. 

*  *  * ** 

Manager  #18. 

I'd  liice  to  see  concurrency  eliminated  as  much  as  possible. 

***** 

Manager  #19. 

You  just  can't  say  concurrency  is  good  or  concurrency  is 
not  good.  You've  got  to  look  at  each  case  and  [ask],  "what 
is  the  need?" 

***** 

Manager  #20. 

Cpt  Foote.  If  you  had  to  do  it  over  again,  would  you  have 
a  concurrent  program? 

Manage  r .  No . 

***** 
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